12 ms·

What to do when tech jobs go bad

196 points by veidr 9y ago

some_account 9y ago
I don't think your solutions will work. It's impossible to get time estimates right for building software. Too many variables in solving the problems, not only in writing code and testing it, but also including open office disturbances and meetings. I understand product owners and businesses wants estimates but software engineering is not making a car. Forcing programmers to estimate their every task makes for a very bad work environment. They are not robots.
- padobson 9y ago
  My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. It requires more project management, but it's much easier to quarantine problems and explain them to stakeholders. My rule of thumb is 4 hours. If you think it will take longer than 4 hours, it should be broken down. Ideally, most tasks will have estimates of 1 hour. That way, when a 2-hour task requires 2 weeks to complete, you can point to the specific task and its challenges. It provides an easy explanation for why the release was late, why the requirements were too ambitious, etc.
  - ethnicify 9y ago
    This is micromanagement. You're describing micromanagement. Engineers do not need to be managed down to the hour. Good grief.
    - padobson 9y ago
      It's actually not micromanagement. It's micro-documentation, which provides more autonomy to the developer, not less. The micro-tasks I'm describing go into a project management system. They are either assigned to or picked by developers who complete and document the micro-tasks on their own. Because the tasks are so small, there is almost no management of developers required. Finally, it's trivial to find out where project estimates went wrong, because any hidden challenges are well-quarantined in the micro-tasks. If the task isn't well documented, it's still pretty easy to go to the developer and find out why it took longer than estimated.
      - 123212321 9y ago
        This sounds like pure misery. No self respecting good developer would work under these conditions.
      - doseofreality 9y ago
        So, if a developer takes too long developing the pre-defined micro-task which you've assigned them, you have to followup with them and report on why a micro-task took too long? If this isn't micromanagement, what would you define as micromanagement?
        beegeezuz 9y ago
        Exactly, I see Devs in our company having small meeting all the time to discuss the most ridiculous things that you could imagine... if Eng ever get micromanaged like this, I'm out in a month.
        fao_ 9y ago
        Hey, this post (and all of your posts) are marked as dead. ~I'm not sure why~
        chrisbennet 9y ago
        A month is too long to wait. Break it down into smaller units... ;-) I think some managers just don’t have enough to do so they make work for themselves (and everyone else). Like a border collie with no sheep to herd, they will start herding ducks, children, etc.
      - drharby 9y ago
        Ive developed a habit of doing this very thing, to the point of drafting release schedules to communicate deadlines to management. I love the liberty with my job but you can hang yourself if you don't watch it
      - aje403 9y ago
        I would definitely consider a gulag over this
    - veidr 9y ago
      In my own experience as a software developer, it is incontrovertibly true that the smaller the unit I/we use to break things down, the more accurate the resultant time estimate becomes. However, as padobson notes, there's an overhead associated with breaking complex things down into smaller units. There's a point at which it becomes counterproductive. I feel like I have, over the years, sometimes crossed that line. (And, other times, not gotten close enough to that line and been surprised by weeks/months of schedule disintegration.)
      - deleted 9y ago
        [deleted]
      - Retric 9y ago
        Smaller tasks have less accurate estimates. If you say something takes 1h and it actually takes two days that's ~16x as long or a week long task taking 4 months. All it takes as a small corner case or odd bug that you did not consider and suddenly your estimates are worthless. The only thing that makes small estimates seem better is the worst case tends to be less time, but overall they don't help.
        shagie 9y ago
        An estimate is not a single number. Rather, an estimate says “it may take 1h if everything goes well, it may take 16h if things go bad.” This is then followed up with “at 1h, I’ll update with either a done or a revised estimate.” Giving single numbers for an estimate with uncertainty is bad for all parties. Additionally, with experience one can get better at giving estimates with less uncertainty for well known tasks and recognize the uncertainty for other tasks.
        Retric 9y ago
        That's not relevant. Low / high estimates can be written in this form: X hours +/- Y%. 1-3 days seems wide but it's just 2 +/- 50%. 1 hour or 2 days ~= 1 day 1 hour +/- 90%. AKA Y is much higher when you deal with low hour estimates. This is most noticeable when you have lot's of tasks. If you think 200 tiny tasks may take 1 month or just over 1 year that's an almost useless estimate.
    - janlaureys 9y ago
      This gives me PTSD to a consulting job I had as a web developer where every 15-30 minutes the project manager would come up to my desk to ask what I've been up to and what I had achieved (in the last 15 minutes). He'd also get upset when the feature I was working on wasn't finished yet since the last meeting.
      - matte_black 9y ago
        With an interruption every 15 minutes, sounds like you would never reach a state of flow.
        ImSkeptical 9y ago
        My own strategy with such people is to bore them into never speaking with me. Every such question, I'll take a moment to compose my thoughts, and then begin explaining, as thoroughly as possible, in a monotonous cadence, exactly what's been going on. I'm also sure to always add that reporting on progress is consuming a significant amount of time, especially because it is an interruption. I also repeat any instruction given to me in different words, and describe what I'm currently working on, what I think the priority of the new thing should be relative to current tasks, and ask if they agree with me. In my experience, people simply lack the will to repeatedly endure lengthy and dull interactions. I can tell they zone out soon after I start talking, and I keep lashing them with boredom until they learn to not interrupt me. I'd suspect the kind of person who asks for an update every fifteen minutes is doing so out of a minor sadistic impulse, rather than for any legitimate reason. If so, the important thing would be never to appear bothered by it. That would be my strategy at least.
      - EKLM-ZK88 9y ago
        I've personally witnessed the VP of product stand over our senior engineer's shoulder while he tried to debug some serious bug that we couldn't reproduce in dev/stage for hours until it was done. That same engineer also had the CEO stand over his shoulder and actually ask "You don't mind if I stand here and watch do you?" The same CEO constantly brags about his "10 years of experience building companies with successful exits"(10 years of experience vs 1 year of experience ten times), and calls his company the "Amazon of the south". Reading this article gave me flashbacks, but it does help to know that it wasn't just that company.
    - ajb257 9y ago
      It's not micromanagement. It's planning. There's nothing wrong with those tasks having no-user facing changes, or giving all the tasks to acheive a higher-level goal to one developer. However, going in and making those tasks forces you to think over the problem properly and come up with a game plan. If you don't know a given approach will work, sometimes that's best to timebox some experimentation time (say an afternoon), but then you can also say to your PM/EM 'ok, we need a little time to work out how long it's going to take', and decisions can be made accordingly as to priorities. Very little of being a software engineer is about writing code. That's just typing. The skill is being able to come up with a coherant plan to solve a problem. That's why architects don't tend to write a lot of code.
  - maxxxxx 9y ago
    This works only if you do things that are well understood beforehand. If you are doing things that require a lot of research and experimentation this project plan falls apart quickly.
    - mateo411 9y ago
      Correct. If you have to do research and experimentation before you can make good estimates, then you need to allocate time to do that. I use the term discovery phase to describe this. You give the discovery phase a certain amount of time to complete, it should be from a few days to 2 weeks. The deliverable at the end of discovery phase is a document. The document explains what experiments were run and what we should do next.
      - maxxxxx 9y ago
        This still rubs me the wrong way. I guess I personally don't like micromanaged environments. I don't want to have to explain every little step and report back all the time to people whose only interest is the deadline. I prefer to be treated like an adult who can be trusted to do the right thing to get to the goal quickly without being supervised at every step. But I know plenty of people who need constant monitoring and handholding.
        atridan 9y ago
        I can see GP's point and I don't see it as micromanagement. It's more like intensive investigation. I was "promoted" into management recently and I've had to change my view from "tasks getting done" to "people working together to complete tasks." Getting people to work together fruitfully is pretty difficult and even more difficult when you have a deadline you're shooting for. I don't care as much for reports back to me on progress, but I definitely like to see communication between those doing the task. This also goes well with the rule mentioned in the article: always have at least 2 people working on a project.
        maxxxxx 9y ago
  - blauditore 9y ago
    I'm pretty sure if you've broken down a larger task to 1-hour pieces, you've already done a large part of the software engineering work. So you've implicitly consumed a considerable amount of (not accounted-for) project time. My impression has always been that the true cost of a dev task is only revealed when solving it. That's why they're hard to estimate. If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. And for the lack of work, we'd aim for the next larger goal (which is again hard to achieve and estimate).
    - hrktb 9y ago
      > If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. This seems to be a concept so hard to grasp for non technical managers. By definition tasks aren’t that similar to other tasks, otherwise we would be a super crappy software shop that can’t provide semi-generic solutions. Dev team’s mission is to solve unique problems to the stack. Discovery is a major time consuming task by definition, and can’t be properly estimated, as it’s an information problem.
  - andyjohnson0 9y ago
    > My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. The problem with this is that the time required to complete all the pieces is almost never equal to the sum of their estimated durations.
  - zintinio5 9y ago
    I would quit this team.
  - expertentipp 9y ago
    My current team is estimating up the to one hour and afterwards reporting the work with an hour resolution. It's low cost center squeezing the last cent form the engineering workforce. We are not asked for opinion or for a decision but to implement the tasks distributed by architects and Scrum masters. I'm quitting this place with the first opportunity possible and before taking all holidays until the end of the notice period. I will not even say goodbye.
    - s73v3r_ 9y ago
      "taking all holidays until the end of the notice period" Do you mean bank holidays? Cause regardless of how you feel about your company, you should always take those. Rest and disconnect from work are important, especially in environments where you really like the work or the job, and the risk of overheating is much greater.
      - vanilla_nut 9y ago
        Presumably he means taking his vacation days so he doesn't have to put in any days of work in the 2 weeks after he puts in his notice. I'd guess he isn't American -- the term "holiday" is interchangeable with "vacation" in most of Europe, for instance. That being said, your point about bank holidays is a good one. Never give your company free labor -- they'll never give you free capital.
        EKLM-ZK88 9y ago
        I would be careful with this, my last employer refused to pay for unspent vacation days, and if you put in your notice or thought the individual was likely to quit they wouldnt approve your PTO requests. I don't know if this is legal (South Florida), but all the information i find online for this state say that the employer is not required to pay out your time (varies by state).
      - expertentipp 9y ago
        I mean withdrawing entire remaining annual leave to spend in the office the minimal time possible during the notice period.
  - laythea 9y ago
    1 hour tasks! Sound like a recent working environment I was in where I witnessed a poor permanent employee driven to booking 10 mins to a task by this mentality from management down. Also, none of them spoke to each other due to the time-micromanagement. No thanks.
  - AFNobody 9y ago
    I think you are overdoing it simply because per-hour estimates are extremely time consuming to produce and borders on micromanagement. Realistically, tasks should be grouped into roughly day-sized estimates for any long project with an equally large QA pool possibly run in parallel. Granularity only gets you so far before the returns diminish to the point of worthlessness. Imho anyway.
- scottinseattle 9y ago
  Are you sure it's impossible to get time estimates right for building software? What do you even mean by that? What methods have you tried and in what context(s)? How much data substantiates your claim? I'm not trying to be a dick, but there's a lot of shit that passes for wisdom online which boils down to, "I tried it once and it didn't work for me." Most software engineers I've spoken to, when challenged, admit they don't know shit about software estimation techniques and haven't even heard of PERT, Wideband Delphi, work breakdown structures, etc, etc. At least read the book Software Estimation: Demystifying the Black Art before you go around saying that it's impossible to get time estimates right for building software. I think if you did, you would be a lot less cavalier about it.
padobson 9y ago
I've seen this at the most basic level of contracting. To me, a lot of these problems come down to cost. I've contracted with a dozen startups and small businesses. Most of these companies will find a young developer charging between $20/hr and $50/hr and have them start coding on their new app/website idea and feel wildly optimistic when they see the first 80% of the project come together. Then it's time for the edge cases, and because there aren't any senior devs on the project, handling those edge cases introduces bugs. Weeks and months pass, and the project that looked like it was a surefire success descends into development hell. But the company never fires the developer. The developer actually quits from being over stressed. Then the company goes looking for a new developer, who tells them they'd be happy to build their software for $20/hr-$50/hr. The new developer comes on, looks at the codebase, decides all of it is crap, and recommends they start over. The new developer finishes 80% of the project in the first week.... rinse and repeat. The company should have hired a developer or firm with a record of success, with actual, running software out in the wild. How they achieved that may or may not line up with the ideas in the OP, but at least the company would know exactly what they're paying for.
- nathanaldensr 9y ago
  I've described this phenomenon to many-a-manager as "assuming that all progress is linear." It's not; in fact, linear progress is extremely rare in my experience. Usually, a "big bang" of progress happens on a project, whether at the beginning or at the end. Recently, I was implementing Pivotal Cloud Foundry for a client. Everyone was assuming PCF would deliver incremental and linear amounts of value during implementation. I had to keep telling folks, "No, it doesn't work that way. PaaS is only valuable at the very end of the implementation, when all the technology is ready and the team has been trained."
  - wil421 9y ago
    Agreed on the linear progress. I’ve been working on implementing various parts of a PaaS/SaaS solution for the past few years. I’d add that the implementation is only as good or mature as your processes. Sometimes the solution and process must mature before you realize the full value.
brooklyn_ashey 9y ago
Excellent condensation of the issues. Great ideals to work toward. Just moving in this direction would be helpful in any industry. If we implemented your codebase ideas in education... well, you know we'd have great education.
Areading314 9y ago
Sounds like a really toxic person to work with. Lots of complaints and few solutions.
- old_haus 9y ago
  Be kind. I agree that my run through of the article seemed to point to problems more than solutions, but I have always felt that the old chestnut 'don't bring me problems, bring me solutions' was a bit shortsighted. Yes, it would be nice if every problem had a solution provided in a gift wrapped box. Yet, it is dangerous to pretend that problems do not exist simply because we do not know how to solve it. Now, how to do this without become overwhelmed and despondent in the face of these problems is another issue.
  - the_new_guy_29 9y ago
    Ive created account only to say "thank you" for writing this article. Thought im just projecting issues that dont really exist because of not so long ride in this bus (just promoted to senior)... At first i tried to tackle those issues but it seems that nobody cares or doesnt want to accept that we have such issues in the first place. Im just happy others see those issues too and try to solve them at least by rising awerness. Im also sure that if i tried to bring this article to discussion i would be fired next day because of "playing primadonna" one of our managers use to say...
- chatmasta 9y ago
  Almost every bulletpoint has a “Solution:” subheader...
blauditore 9y ago
> Providing regular events with alcohol. Peer pressure to drink, bad health habits, bad workplace environment. > Normalizing and glorifying drinking alcohol. Sure, alcohol is not healthy, and peer pressure to drink is bad. But I've found such events to lower some barriers and help connect with people I would usually hardly talk to short of hi and bye. And I think this may affect work productivity as well as personal happiness in a positive way.
- atridan 9y ago
  I used to have a "no drinking with coworkers" policy, but I loosened that a bit. At smaller, team events I have one drink per hour. At larger company events it's one drink every two hours. In either case it comes out to two drinks per event. But, if I see everyone else getting sloshed at events, I usually step out before things get awkward.
- michaelt 9y ago
  Regular is a very vague term. After all, "optional one pint of beer after work, once a month" is regular. "Two or three pints a day, starting at 3pm" is also regular - but sixty times as much.
- s73v3r_ 9y ago
  The problem with that is, not everyone likes or can have alcohol. If all your events are centered mainly around alcohol, then you're isolating those people from cultures where alcohol use is not common or frowned upon, those people who may have problems with alcohol, and those people who just plain don't want to drink. I'm not saying never have alcohol at company events, far from it. But don't have every event be centered around it. If you're going to do company events, you need to have a variety of different things, so that, while not every event is everyone's cup of tea, people don't feel isolated at every event, either.
  - Zelphyr 9y ago
    This does seem to be growing into a problem. I have a friend who is a recovering alcoholic and recently he went to a tech meetup where not only was it centered around alcohol but there really wasn't anything else provided. He rightly chided the organizer for not considering that there might be people who want to attend who don't consume alcohol.
trey-jones 9y ago
I honestly read 2 paragraphs before deciding that a large part of the problem is the author's inability to work through adversity. Maybe even an industry culture of avoiding adversity rather than dealing with it (aka laziness).
- s73v3r_ 9y ago
  Really? I saw a bunch of things that happen when management doesn't want to be held accountable. I saw a bunch of things that end up coming back to the developer to bite them in the ass. I saw a bunch of things that make for long hours and late nights for no valid reason. Basically, I did see a bunch of adversity, but artificial adversity. Adversity that doesn't make anyone stronger, or better, or even feeling accomplished. Just a bunch of bullshit that one had to wade through. And if you're in the position in your career where you have alternatives, why on earth would you decide to stay in that environment?
bprasanna 9y ago
Good to see someone took the effort to document the commonly prevalent issues and probable solutions. Doesn't matter how many facts can be arguable or the how much credibility be questionable about the person, finally it boils down to he took the time and effort to document it and share it. Discussion can follow, but there should be something existing to discuss about.
a_imho 9y ago
“The company is a family.” No it is not, and if it were, many companies behave like an abusive parent, where the child keeps giving, and the parent keeps expecting and punishing. I often wonder what happened to being professional. If someone ever says they prioritize working for actual money over being passionate about changing the world while basking in the vision of some VIP on the board that's like admitting murder. I see this mindset more and more in non-tech jobs as well.
- sixdimensional 9y ago
  This one bit me. When I was fresh out of school I worked for a "from the garage" startup. I was naive and working around the clock nights and weekends, and the owners told me to think of it like I was part of a family. I fell for it, thinking "we are all in this together" and using it to justify the stress and hard work. When the company succeeded, due in part to the systems I built and designed from scratch, I was unceremoniously asked to leave a few weeks before the transaction closed for many millions. I was asked to leave because as we drew nearer to a sale of the company, I had the nerve to ask for the company to put on paper how I would be a part of that transaction, since I had been verbally promised that "a rising tide floats all boats" and I would be rewarded handsomely for my work. Mistake #2 of 1000 then, accepting a verbal agreement over one in writing. In the end, when I asked about getting it in writing so close to the sale, I was asked to leave. When I said, "but, you told me I was to think of this like a family", I was told, "we thought you were smarter than that". That episode did a lot of damage, and I never saw anything meaningful in terms of compensation- the owners got fabulously wealthy. I made many mistakes then, and I could have pursued legal action, but it was all too painful. Since then I always try to insulate my feelings and remember that in a professional setting I can always do my best and be professional, but to always remember that to others, it really can be "just business". It's important to keep some distance and avoid emotional abuse at work, both doing it and receiving it. It's not to say we can't be friendly, but just to be professional, honest and ethical in the workplace, always. Edit: I meant to mention, that in this job, I was working for the "changing the world part", but when I saw the imminent sale coming and I had nothing, felt I had to ask if I would be a part of it. Back then, it was a mistake for me as well, to assume that I was going to do good and get handsomely rewarded and expect that the two would come together. I think it can happen, but I learned the hard way how to compartmentalize changing the world and getting paid with simply doing necessary work to get paid and survive.
atridan 9y ago
> Writing new systems that don’t need to exist simply to scratch an itch to write (NIH syndrome, etc.) I've seen this so many times and it almost always ends in failure. Rewrites as well. Engineers can't resist improving a system while rewriting it (adding caching, redundancy, etc). They neglect proving core functionality is intact before making improvements. They also often neglect the thousands of man hours it took to find all the bugs in the system. I've been building ML systems for a while and I've even seen engineers coming up with their own search/optimization algorithms. This always fails. It's hard enough to get standard techniques to work, since your data usually differs (slightly or severely) from what the technique was validated on (standard, cleaned data sets used for journal papers).
hitekker 9y ago
This article describes how the author would deal with or avoid various pitfalls in a business environment. It's truthful and not "whiney", as the more sociopathic among us are quick to sneer. However, an underlying thread is needed to weave these criticisms into a meaningful critique. Mismanagement is a theme, but, alone, is insufficient for making the piece persuasive or insightful.
rampage101 9y ago
Great article. The one that hit home for me "One lone engineer on a big project silo’ed away". Was on a project where we had multiple applications. The team had a new employee code an entire system as a prototype but then it was decided to put it into production. Nobody ever reviewed this code, and that engineer told me himself that the code was crap. He left the project to get away from this code and I inherited a mess, with nobody to ask questions from. To make matters worse, the entire company relied on this system and there were about 20 regular users of this system. I was responsible for handling all of their feature requests and support which was often. Many bugs I fixed were extremely challenging edge cases, and there was zero appreciation for the complexity of many of these. My manager was telling others at the company the code was solid, and it's "just python code" which can be figured out. I notified the company I was leaving and they begged me to stay. Even offered to "release" me and hire me at a higher salary under another manager. The only issue was I would be required to support this same project. My manager refused to give me a release date so I had to call HR and tell them I needed to leave at any cost. Pretty sure it's a disaster there since I left.
- chatmasta 9y ago
  This happens a lot with non-technical founders hiring contractors or employees. At first, the goal is “build a prototype,” then it’s “make this an MVP,” and then finally “what’s left to get this to production?” I don’t blame founders for this; I blame the programmers, especially if they’re consultants. This is a symptom of failure to manage expectations of stakeholders. As a developer, your job is to show the stakeholders what the tradeoffs of different decisions are, both in terms of immediate time to results, and technical debt. If you hear “make a prototype,” you better ask for a projected lifetime of the prototype, and discuss with the stakeholders the tradeoffs of quickly building a prototype, making sure they understand it could mean more work later to productionize it, in exchange for less work up front. Also as a developer, you should realize that nothing is ever a prototype. Don’t use “it’s a prototype” as an excuse for writing unmaintanable and insecure code, because eventually someone is going to want to add some features to it. Good luck telling the stakeholders after three months of building a prototype that you need to start from scratch because the code is awful. This is especially difficult if the prototype looks like a fully functioning product (with minimal features) to the stakeholders, but you as a developer know that under the hood it’s completelty unmaintainable. It’s better to take the time up front to put in place whatever you need to write quality code, than it is to take shortcuts and write bad code. A good developer will be able to explain this to a stakeholder, instead of caving under pressure to rush a prototype.
tschellenbach 9y ago
We do a weekly standup with the team (working on the same product) and monthly company all hands. It's very useful to be aware of what everyone is working on. Sure it takes 15 minutes and it's a distraction. Thats why we do it only once a week in person and every day via a Slack channel (simple message, hi i'm working on xyz today). Not doing a standup makes it easier for things to go off track. People working on the wrong things, making mistakes with prioritization by not being aware of what other people are working on. Maybe you don't notice this as much as an individual contributor. As a manager I've seen this go wrong so many times. The group of people should be relatively small. Definitely < 20. But for that group every should have a rough idea of what everyone else is working on. It's also the realization that I can't/won't fully plan out someone's personal roadmap for them. They need to understand what the team is working on, what the business priorities are and make their own tradeoffs. I set high level priorities of course, but I think people should have control/ownership over their day to day tasks.
- capitalsigma 9y ago
  I agree. I attend a few meetings whose main purpose is to hear about what's going on with teams whose work is only tangentially related to mine. Sometimes it ends up being useful ("oh, you're stuck on XYZ problem? I think C works on that -- go ask him").
asow92 9y ago
Get a hobby. Relax and don't take work so seriously. I'm not saying avoid responsibilities, but do the best you can and lead by example.
karmakaze 9y ago
> Excessive democracy leading to indecision This is one I've hit a number of times, my solution in the past has been to 'go rogue' and get something done, people will be bothered (usually someone unofficially says it's a good idea), if it works out often enough, we'll start 'deciding' to do more things if for no other reason than to take some credit. While reading, I was trying to come up with a cohesive idea as to why these things happen, or what single thing could prevent them. The best I could come up with is having a good 'Director of Development' or maybe Project Lead. I don't know what the title should be because I haven't really worked for one. I've worked with great team leads and companies with fine CEOs. CTO's are rarely close enough to the problems being solved and often just not available. I myself worked as a Director of Development for a small startup that eventually ran out of runway. The dev's said they enjoyed working together but I don't think it was long enough or going through the many pivots to test out how that would have been. Most places I've been have business people that plan projects. Then there are product owners and PMs with teams, design/UX, front-end, back-end, SRE/devops, sometimes even multiple teams with overlapping roles to execute. This I know, doesn't work for long. Startups that grow and promote internally to fill such a role, may or may not work--depends on the individual. What's really needed is good alignment and balance of business goals and employee happiness. Two things which are both true: startups need to iterate fast to find that magic point; employees are a company's greatest asset. You can't forsake one for the other.
- karmakaze 9y ago
  > [0] Please don't comment about the voting on comments. It never does any good, and it makes boring reading. Despite the quoted item, I couldn't see how to understand the (incorrect?) use of downvoting comments as disagreement rather than to discourage unwanted behaviour which doesn't contribute to a discussion. In any case, a comment as to why is always helpful. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
chatmasta 9y ago
> Someone has a great new design they want to implement which is leagues better than what exists, and the existing design is just so awful. Only, it’s going to require some duct tape here and there, but that’s totally acceptable because overall it’s better. Until it becomes apparent that it’s mostly duct tape, but you’ve gone all-in on this and you can’t go back. > Solution: Start over. The sunken cost fallacy is real. You’ve made a mistake, and that’s ok, you can take those learnings and build something better. Don’t settle for chaos. Seems like a smart solution, and yet I almost never hear “throw it out and start over” as an option for dealing with unforeseen problems. Perhaps as programmers we should take some lessons from writers, who will often throw out all their work from the past day/week/month, because once it goes into production (a published book), you can’t change it. In software, you can change it, yes. But if it doesn’t add anything useful, complicates existing things, or will slow development in the future, there is a clear reason to just drop it and move onto the next approach. One way to make “just drop it” a more palatable option is to give yourself a grace period from the outset. Something like “if we can’t get this to work in a week, we’ll drop it and reevaluate.” This is when it helps to have at least two people (engineer + manager, or engineer x2) because it eliminates “developer pride” as a variable in decision making and holds someone accountable for making that decision after a week. As a manager, often the most important decisions are not what to build, but what not to build.
amriksohata 9y ago
In the UK in the last ten years the average salary for a senior developer has gone up from £35k to nearly £50k but for contractors, weirdly the average rate outside of London has stayed around £350 a day
methodover 9y ago
Loved this. And I agree with most of it. One thing I disagree with (and I know this puts me in the minority) is code review. Code review for trusted engineers is a waste of time. You're only going to find those bugs that are very hard to see. And the odds of you catching them in code review are very low. Also, if you're a kind of fast moving startup (like my company is) there's so much new code coming through that it is a serious slowdown to review it all. At least at the level where you'd need to if you're going to catch the things that the original author missed. I only make juniors and new hires do code reviews. I'll also ask for code reviews if an engineer is taking on a task that's totally new for them. But otherwise we've totally cut them out and been fine.
- lovich 9y ago
  Eh, half the benefit of code review on teams I've been on is just making the other engineers aware of what's going on. 75% of the code reviews are just a "good to go", the other 20% are questions about why a change was made that inform the other engineers about that particular business constraint, and the last 5% are actual issues. As you said, it's completely different for junior engineers where it ends up being more like 90% bugs/tech debt, but the code reviews aren't all useless
  - nojvek 9y ago
    100% - Most code reviews are. Why are you doing this? please add a comment. Wait! this will break this other thing in some obscure way. Or hey! I built this other thing over here, let's re-use it.
- ndh2 9y ago
  In my opinion the main benefit of code review is diffusion of knowledge. It's kind of pointless to let new hires do reviews.
  - methodover 9y ago
    What knowledge, specifically?
rustoo 9y ago
This post would still hold true if replace the phrase 'tech jobs' with just 'jobs' :) Such a wonderful article on all things wrong at the workplace these days.

196 points by veidr 9y ago

I don't think your solutions will work. It's impossible to get time estimates right for building software. Too many variables in solving the problems, not only in writing code and testing it, but also including open office disturbances and meetings. I understand product owners and businesses wants estimates but software engineering is not making a car. Forcing programmers to estimate their every task makes for a very bad work environment. They are not robots.

padobson 9y ago
My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. It requires more project management, but it's much easier to quarantine problems and explain them to stakeholders. My rule of thumb is 4 hours. If you think it will take longer than 4 hours, it should be broken down. Ideally, most tasks will have estimates of 1 hour. That way, when a 2-hour task requires 2 weeks to complete, you can point to the specific task and its challenges. It provides an easy explanation for why the release was late, why the requirements were too ambitious, etc.
- ethnicify 9y ago
  This is micromanagement. You're describing micromanagement. Engineers do not need to be managed down to the hour. Good grief.
  - padobson 9y ago
    It's actually not micromanagement. It's micro-documentation, which provides more autonomy to the developer, not less. The micro-tasks I'm describing go into a project management system. They are either assigned to or picked by developers who complete and document the micro-tasks on their own. Because the tasks are so small, there is almost no management of developers required. Finally, it's trivial to find out where project estimates went wrong, because any hidden challenges are well-quarantined in the micro-tasks. If the task isn't well documented, it's still pretty easy to go to the developer and find out why it took longer than estimated.
    - 123212321 9y ago
      This sounds like pure misery. No self respecting good developer would work under these conditions.
    - doseofreality 9y ago
      So, if a developer takes too long developing the pre-defined micro-task which you've assigned them, you have to followup with them and report on why a micro-task took too long? If this isn't micromanagement, what would you define as micromanagement?
      - beegeezuz 9y ago
        Exactly, I see Devs in our company having small meeting all the time to discuss the most ridiculous things that you could imagine... if Eng ever get micromanaged like this, I'm out in a month.
        fao_ 9y ago
        Hey, this post (and all of your posts) are marked as dead. ~I'm not sure why~
        chrisbennet 9y ago
        A month is too long to wait. Break it down into smaller units... ;-) I think some managers just don’t have enough to do so they make work for themselves (and everyone else). Like a border collie with no sheep to herd, they will start herding ducks, children, etc.
    - drharby 9y ago
      Ive developed a habit of doing this very thing, to the point of drafting release schedules to communicate deadlines to management. I love the liberty with my job but you can hang yourself if you don't watch it
    - aje403 9y ago
      I would definitely consider a gulag over this
  - veidr 9y ago
    In my own experience as a software developer, it is incontrovertibly true that the smaller the unit I/we use to break things down, the more accurate the resultant time estimate becomes. However, as padobson notes, there's an overhead associated with breaking complex things down into smaller units. There's a point at which it becomes counterproductive. I feel like I have, over the years, sometimes crossed that line. (And, other times, not gotten close enough to that line and been surprised by weeks/months of schedule disintegration.)
    - deleted 9y ago
      [deleted]
    - Retric 9y ago
      Smaller tasks have less accurate estimates. If you say something takes 1h and it actually takes two days that's ~16x as long or a week long task taking 4 months. All it takes as a small corner case or odd bug that you did not consider and suddenly your estimates are worthless. The only thing that makes small estimates seem better is the worst case tends to be less time, but overall they don't help.
      - shagie 9y ago
        An estimate is not a single number. Rather, an estimate says “it may take 1h if everything goes well, it may take 16h if things go bad.” This is then followed up with “at 1h, I’ll update with either a done or a revised estimate.” Giving single numbers for an estimate with uncertainty is bad for all parties. Additionally, with experience one can get better at giving estimates with less uncertainty for well known tasks and recognize the uncertainty for other tasks.
        Retric 9y ago
        That's not relevant. Low / high estimates can be written in this form: X hours +/- Y%. 1-3 days seems wide but it's just 2 +/- 50%. 1 hour or 2 days ~= 1 day 1 hour +/- 90%. AKA Y is much higher when you deal with low hour estimates. This is most noticeable when you have lot's of tasks. If you think 200 tiny tasks may take 1 month or just over 1 year that's an almost useless estimate.
  - janlaureys 9y ago
    This gives me PTSD to a consulting job I had as a web developer where every 15-30 minutes the project manager would come up to my desk to ask what I've been up to and what I had achieved (in the last 15 minutes). He'd also get upset when the feature I was working on wasn't finished yet since the last meeting.
    - matte_black 9y ago
      With an interruption every 15 minutes, sounds like you would never reach a state of flow.
      - ImSkeptical 9y ago
        My own strategy with such people is to bore them into never speaking with me. Every such question, I'll take a moment to compose my thoughts, and then begin explaining, as thoroughly as possible, in a monotonous cadence, exactly what's been going on. I'm also sure to always add that reporting on progress is consuming a significant amount of time, especially because it is an interruption. I also repeat any instruction given to me in different words, and describe what I'm currently working on, what I think the priority of the new thing should be relative to current tasks, and ask if they agree with me. In my experience, people simply lack the will to repeatedly endure lengthy and dull interactions. I can tell they zone out soon after I start talking, and I keep lashing them with boredom until they learn to not interrupt me. I'd suspect the kind of person who asks for an update every fifteen minutes is doing so out of a minor sadistic impulse, rather than for any legitimate reason. If so, the important thing would be never to appear bothered by it. That would be my strategy at least.
    - EKLM-ZK88 9y ago
      I've personally witnessed the VP of product stand over our senior engineer's shoulder while he tried to debug some serious bug that we couldn't reproduce in dev/stage for hours until it was done. That same engineer also had the CEO stand over his shoulder and actually ask "You don't mind if I stand here and watch do you?" The same CEO constantly brags about his "10 years of experience building companies with successful exits"(10 years of experience vs 1 year of experience ten times), and calls his company the "Amazon of the south". Reading this article gave me flashbacks, but it does help to know that it wasn't just that company.
  - ajb257 9y ago
    It's not micromanagement. It's planning. There's nothing wrong with those tasks having no-user facing changes, or giving all the tasks to acheive a higher-level goal to one developer. However, going in and making those tasks forces you to think over the problem properly and come up with a game plan. If you don't know a given approach will work, sometimes that's best to timebox some experimentation time (say an afternoon), but then you can also say to your PM/EM 'ok, we need a little time to work out how long it's going to take', and decisions can be made accordingly as to priorities. Very little of being a software engineer is about writing code. That's just typing. The skill is being able to come up with a coherant plan to solve a problem. That's why architects don't tend to write a lot of code.
- maxxxxx 9y ago
  This works only if you do things that are well understood beforehand. If you are doing things that require a lot of research and experimentation this project plan falls apart quickly.
  - mateo411 9y ago
    Correct. If you have to do research and experimentation before you can make good estimates, then you need to allocate time to do that. I use the term discovery phase to describe this. You give the discovery phase a certain amount of time to complete, it should be from a few days to 2 weeks. The deliverable at the end of discovery phase is a document. The document explains what experiments were run and what we should do next.
    - maxxxxx 9y ago
      This still rubs me the wrong way. I guess I personally don't like micromanaged environments. I don't want to have to explain every little step and report back all the time to people whose only interest is the deadline. I prefer to be treated like an adult who can be trusted to do the right thing to get to the goal quickly without being supervised at every step. But I know plenty of people who need constant monitoring and handholding.
      - atridan 9y ago
        I can see GP's point and I don't see it as micromanagement. It's more like intensive investigation. I was "promoted" into management recently and I've had to change my view from "tasks getting done" to "people working together to complete tasks." Getting people to work together fruitfully is pretty difficult and even more difficult when you have a deadline you're shooting for. I don't care as much for reports back to me on progress, but I definitely like to see communication between those doing the task. This also goes well with the rule mentioned in the article: always have at least 2 people working on a project.
        maxxxxx 9y ago
- blauditore 9y ago
  I'm pretty sure if you've broken down a larger task to 1-hour pieces, you've already done a large part of the software engineering work. So you've implicitly consumed a considerable amount of (not accounted-for) project time. My impression has always been that the true cost of a dev task is only revealed when solving it. That's why they're hard to estimate. If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. And for the lack of work, we'd aim for the next larger goal (which is again hard to achieve and estimate).
  - hrktb 9y ago
    > If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. This seems to be a concept so hard to grasp for non technical managers. By definition tasks aren’t that similar to other tasks, otherwise we would be a super crappy software shop that can’t provide semi-generic solutions. Dev team’s mission is to solve unique problems to the stack. Discovery is a major time consuming task by definition, and can’t be properly estimated, as it’s an information problem.
- andyjohnson0 9y ago
  > My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. The problem with this is that the time required to complete all the pieces is almost never equal to the sum of their estimated durations.
- zintinio5 9y ago
  I would quit this team.
- expertentipp 9y ago
  My current team is estimating up the to one hour and afterwards reporting the work with an hour resolution. It's low cost center squeezing the last cent form the engineering workforce. We are not asked for opinion or for a decision but to implement the tasks distributed by architects and Scrum masters. I'm quitting this place with the first opportunity possible and before taking all holidays until the end of the notice period. I will not even say goodbye.
  - s73v3r_ 9y ago
    "taking all holidays until the end of the notice period" Do you mean bank holidays? Cause regardless of how you feel about your company, you should always take those. Rest and disconnect from work are important, especially in environments where you really like the work or the job, and the risk of overheating is much greater.
    - vanilla_nut 9y ago
      Presumably he means taking his vacation days so he doesn't have to put in any days of work in the 2 weeks after he puts in his notice. I'd guess he isn't American -- the term "holiday" is interchangeable with "vacation" in most of Europe, for instance. That being said, your point about bank holidays is a good one. Never give your company free labor -- they'll never give you free capital.
      - EKLM-ZK88 9y ago
        I would be careful with this, my last employer refused to pay for unspent vacation days, and if you put in your notice or thought the individual was likely to quit they wouldnt approve your PTO requests. I don't know if this is legal (South Florida), but all the information i find online for this state say that the employer is not required to pay out your time (varies by state).
    - expertentipp 9y ago
      I mean withdrawing entire remaining annual leave to spend in the office the minimal time possible during the notice period.
- laythea 9y ago
  1 hour tasks! Sound like a recent working environment I was in where I witnessed a poor permanent employee driven to booking 10 mins to a task by this mentality from management down. Also, none of them spoke to each other due to the time-micromanagement. No thanks.
- AFNobody 9y ago
  I think you are overdoing it simply because per-hour estimates are extremely time consuming to produce and borders on micromanagement. Realistically, tasks should be grouped into roughly day-sized estimates for any long project with an equally large QA pool possibly run in parallel. Granularity only gets you so far before the returns diminish to the point of worthlessness. Imho anyway.
scottinseattle 9y ago
Are you sure it's impossible to get time estimates right for building software? What do you even mean by that? What methods have you tried and in what context(s)? How much data substantiates your claim? I'm not trying to be a dick, but there's a lot of shit that passes for wisdom online which boils down to, "I tried it once and it didn't work for me." Most software engineers I've spoken to, when challenged, admit they don't know shit about software estimation techniques and haven't even heard of PERT, Wideband Delphi, work breakdown structures, etc, etc. At least read the book Software Estimation: Demystifying the Black Art before you go around saying that it's impossible to get time estimates right for building software. I think if you did, you would be a lot less cavalier about it.

padobson 9y ago

I've seen this at the most basic level of contracting. To me, a lot of these problems come down to cost. I've contracted with a dozen startups and small businesses. Most of these companies will find a young developer charging between $20/hr and $50/hr and have them start coding on their new app/website idea and feel wildly optimistic when they see the first 80% of the project come together. Then it's time for the edge cases, and because there aren't any senior devs on the project, handling those edge cases introduces bugs. Weeks and months pass, and the project that looked like it was a surefire success descends into development hell. But the company never fires the developer. The developer actually quits from being over stressed. Then the company goes looking for a new developer, who tells them they'd be happy to build their software for $20/hr-$50/hr. The new developer comes on, looks at the codebase, decides all of it is crap, and recommends they start over. The new developer finishes 80% of the project in the first week.... rinse and repeat. The company should have hired a developer or firm with a record of success, with actual, running software out in the wild. How they achieved that may or may not line up with the ideas in the OP, but at least the company would know exactly what they're paying for.

nathanaldensr 9y ago
I've described this phenomenon to many-a-manager as "assuming that all progress is linear." It's not; in fact, linear progress is extremely rare in my experience. Usually, a "big bang" of progress happens on a project, whether at the beginning or at the end. Recently, I was implementing Pivotal Cloud Foundry for a client. Everyone was assuming PCF would deliver incremental and linear amounts of value during implementation. I had to keep telling folks, "No, it doesn't work that way. PaaS is only valuable at the very end of the implementation, when all the technology is ready and the team has been trained."
- wil421 9y ago
  Agreed on the linear progress. I’ve been working on implementing various parts of a PaaS/SaaS solution for the past few years. I’d add that the implementation is only as good or mature as your processes. Sometimes the solution and process must mature before you realize the full value.

brooklyn_ashey 9y ago

Excellent condensation of the issues. Great ideals to work toward. Just moving in this direction would be helpful in any industry. If we implemented your codebase ideas in education... well, you know we'd have great education.

Areading314 9y ago

Sounds like a really toxic person to work with. Lots of complaints and few solutions.

old_haus 9y ago
Be kind. I agree that my run through of the article seemed to point to problems more than solutions, but I have always felt that the old chestnut 'don't bring me problems, bring me solutions' was a bit shortsighted. Yes, it would be nice if every problem had a solution provided in a gift wrapped box. Yet, it is dangerous to pretend that problems do not exist simply because we do not know how to solve it. Now, how to do this without become overwhelmed and despondent in the face of these problems is another issue.
- the_new_guy_29 9y ago
  Ive created account only to say "thank you" for writing this article. Thought im just projecting issues that dont really exist because of not so long ride in this bus (just promoted to senior)... At first i tried to tackle those issues but it seems that nobody cares or doesnt want to accept that we have such issues in the first place. Im just happy others see those issues too and try to solve them at least by rising awerness. Im also sure that if i tried to bring this article to discussion i would be fired next day because of "playing primadonna" one of our managers use to say...
chatmasta 9y ago
Almost every bulletpoint has a “Solution:” subheader...

blauditore 9y ago

> Providing regular events with alcohol. Peer pressure to drink, bad health habits, bad workplace environment. > Normalizing and glorifying drinking alcohol. Sure, alcohol is not healthy, and peer pressure to drink is bad. But I've found such events to lower some barriers and help connect with people I would usually hardly talk to short of hi and bye. And I think this may affect work productivity as well as personal happiness in a positive way.

atridan 9y ago
I used to have a "no drinking with coworkers" policy, but I loosened that a bit. At smaller, team events I have one drink per hour. At larger company events it's one drink every two hours. In either case it comes out to two drinks per event. But, if I see everyone else getting sloshed at events, I usually step out before things get awkward.
michaelt 9y ago
Regular is a very vague term. After all, "optional one pint of beer after work, once a month" is regular. "Two or three pints a day, starting at 3pm" is also regular - but sixty times as much.
s73v3r_ 9y ago
The problem with that is, not everyone likes or can have alcohol. If all your events are centered mainly around alcohol, then you're isolating those people from cultures where alcohol use is not common or frowned upon, those people who may have problems with alcohol, and those people who just plain don't want to drink. I'm not saying never have alcohol at company events, far from it. But don't have every event be centered around it. If you're going to do company events, you need to have a variety of different things, so that, while not every event is everyone's cup of tea, people don't feel isolated at every event, either.
- Zelphyr 9y ago
  This does seem to be growing into a problem. I have a friend who is a recovering alcoholic and recently he went to a tech meetup where not only was it centered around alcohol but there really wasn't anything else provided. He rightly chided the organizer for not considering that there might be people who want to attend who don't consume alcohol.

trey-jones 9y ago

I honestly read 2 paragraphs before deciding that a large part of the problem is the author's inability to work through adversity. Maybe even an industry culture of avoiding adversity rather than dealing with it (aka laziness).

s73v3r_ 9y ago
Really? I saw a bunch of things that happen when management doesn't want to be held accountable. I saw a bunch of things that end up coming back to the developer to bite them in the ass. I saw a bunch of things that make for long hours and late nights for no valid reason. Basically, I did see a bunch of adversity, but artificial adversity. Adversity that doesn't make anyone stronger, or better, or even feeling accomplished. Just a bunch of bullshit that one had to wade through. And if you're in the position in your career where you have alternatives, why on earth would you decide to stay in that environment?

bprasanna 9y ago

Good to see someone took the effort to document the commonly prevalent issues and probable solutions. Doesn't matter how many facts can be arguable or the how much credibility be questionable about the person, finally it boils down to he took the time and effort to document it and share it. Discussion can follow, but there should be something existing to discuss about.

a_imho 9y ago

“The company is a family.” No it is not, and if it were, many companies behave like an abusive parent, where the child keeps giving, and the parent keeps expecting and punishing. I often wonder what happened to being professional. If someone ever says they prioritize working for actual money over being passionate about changing the world while basking in the vision of some VIP on the board that's like admitting murder. I see this mindset more and more in non-tech jobs as well.

sixdimensional 9y ago
This one bit me. When I was fresh out of school I worked for a "from the garage" startup. I was naive and working around the clock nights and weekends, and the owners told me to think of it like I was part of a family. I fell for it, thinking "we are all in this together" and using it to justify the stress and hard work. When the company succeeded, due in part to the systems I built and designed from scratch, I was unceremoniously asked to leave a few weeks before the transaction closed for many millions. I was asked to leave because as we drew nearer to a sale of the company, I had the nerve to ask for the company to put on paper how I would be a part of that transaction, since I had been verbally promised that "a rising tide floats all boats" and I would be rewarded handsomely for my work. Mistake #2 of 1000 then, accepting a verbal agreement over one in writing. In the end, when I asked about getting it in writing so close to the sale, I was asked to leave. When I said, "but, you told me I was to think of this like a family", I was told, "we thought you were smarter than that". That episode did a lot of damage, and I never saw anything meaningful in terms of compensation- the owners got fabulously wealthy. I made many mistakes then, and I could have pursued legal action, but it was all too painful. Since then I always try to insulate my feelings and remember that in a professional setting I can always do my best and be professional, but to always remember that to others, it really can be "just business". It's important to keep some distance and avoid emotional abuse at work, both doing it and receiving it. It's not to say we can't be friendly, but just to be professional, honest and ethical in the workplace, always. Edit: I meant to mention, that in this job, I was working for the "changing the world part", but when I saw the imminent sale coming and I had nothing, felt I had to ask if I would be a part of it. Back then, it was a mistake for me as well, to assume that I was going to do good and get handsomely rewarded and expect that the two would come together. I think it can happen, but I learned the hard way how to compartmentalize changing the world and getting paid with simply doing necessary work to get paid and survive.

atridan 9y ago

> Writing new systems that don’t need to exist simply to scratch an itch to write (NIH syndrome, etc.) I've seen this so many times and it almost always ends in failure. Rewrites as well. Engineers can't resist improving a system while rewriting it (adding caching, redundancy, etc). They neglect proving core functionality is intact before making improvements. They also often neglect the thousands of man hours it took to find all the bugs in the system. I've been building ML systems for a while and I've even seen engineers coming up with their own search/optimization algorithms. This always fails. It's hard enough to get standard techniques to work, since your data usually differs (slightly or severely) from what the technique was validated on (standard, cleaned data sets used for journal papers).

hitekker 9y ago

This article describes how the author would deal with or avoid various pitfalls in a business environment. It's truthful and not "whiney", as the more sociopathic among us are quick to sneer. However, an underlying thread is needed to weave these criticisms into a meaningful critique. Mismanagement is a theme, but, alone, is insufficient for making the piece persuasive or insightful.

rampage101 9y ago

Great article. The one that hit home for me "One lone engineer on a big project silo’ed away". Was on a project where we had multiple applications. The team had a new employee code an entire system as a prototype but then it was decided to put it into production. Nobody ever reviewed this code, and that engineer told me himself that the code was crap. He left the project to get away from this code and I inherited a mess, with nobody to ask questions from. To make matters worse, the entire company relied on this system and there were about 20 regular users of this system. I was responsible for handling all of their feature requests and support which was often. Many bugs I fixed were extremely challenging edge cases, and there was zero appreciation for the complexity of many of these. My manager was telling others at the company the code was solid, and it's "just python code" which can be figured out. I notified the company I was leaving and they begged me to stay. Even offered to "release" me and hire me at a higher salary under another manager. The only issue was I would be required to support this same project. My manager refused to give me a release date so I had to call HR and tell them I needed to leave at any cost. Pretty sure it's a disaster there since I left.

chatmasta 9y ago
This happens a lot with non-technical founders hiring contractors or employees. At first, the goal is “build a prototype,” then it’s “make this an MVP,” and then finally “what’s left to get this to production?” I don’t blame founders for this; I blame the programmers, especially if they’re consultants. This is a symptom of failure to manage expectations of stakeholders. As a developer, your job is to show the stakeholders what the tradeoffs of different decisions are, both in terms of immediate time to results, and technical debt. If you hear “make a prototype,” you better ask for a projected lifetime of the prototype, and discuss with the stakeholders the tradeoffs of quickly building a prototype, making sure they understand it could mean more work later to productionize it, in exchange for less work up front. Also as a developer, you should realize that nothing is ever a prototype. Don’t use “it’s a prototype” as an excuse for writing unmaintanable and insecure code, because eventually someone is going to want to add some features to it. Good luck telling the stakeholders after three months of building a prototype that you need to start from scratch because the code is awful. This is especially difficult if the prototype looks like a fully functioning product (with minimal features) to the stakeholders, but you as a developer know that under the hood it’s completelty unmaintainable. It’s better to take the time up front to put in place whatever you need to write quality code, than it is to take shortcuts and write bad code. A good developer will be able to explain this to a stakeholder, instead of caving under pressure to rush a prototype.

tschellenbach 9y ago

We do a weekly standup with the team (working on the same product) and monthly company all hands. It's very useful to be aware of what everyone is working on. Sure it takes 15 minutes and it's a distraction. Thats why we do it only once a week in person and every day via a Slack channel (simple message, hi i'm working on xyz today). Not doing a standup makes it easier for things to go off track. People working on the wrong things, making mistakes with prioritization by not being aware of what other people are working on. Maybe you don't notice this as much as an individual contributor. As a manager I've seen this go wrong so many times. The group of people should be relatively small. Definitely < 20. But for that group every should have a rough idea of what everyone else is working on. It's also the realization that I can't/won't fully plan out someone's personal roadmap for them. They need to understand what the team is working on, what the business priorities are and make their own tradeoffs. I set high level priorities of course, but I think people should have control/ownership over their day to day tasks.

capitalsigma 9y ago
I agree. I attend a few meetings whose main purpose is to hear about what's going on with teams whose work is only tangentially related to mine. Sometimes it ends up being useful ("oh, you're stuck on XYZ problem? I think C works on that -- go ask him").

asow92 9y ago

Get a hobby. Relax and don't take work so seriously. I'm not saying avoid responsibilities, but do the best you can and lead by example.

karmakaze 9y ago

> Excessive democracy leading to indecision This is one I've hit a number of times, my solution in the past has been to 'go rogue' and get something done, people will be bothered (usually someone unofficially says it's a good idea), if it works out often enough, we'll start 'deciding' to do more things if for no other reason than to take some credit. While reading, I was trying to come up with a cohesive idea as to why these things happen, or what single thing could prevent them. The best I could come up with is having a good 'Director of Development' or maybe Project Lead. I don't know what the title should be because I haven't really worked for one. I've worked with great team leads and companies with fine CEOs. CTO's are rarely close enough to the problems being solved and often just not available. I myself worked as a Director of Development for a small startup that eventually ran out of runway. The dev's said they enjoyed working together but I don't think it was long enough or going through the many pivots to test out how that would have been. Most places I've been have business people that plan projects. Then there are product owners and PMs with teams, design/UX, front-end, back-end, SRE/devops, sometimes even multiple teams with overlapping roles to execute. This I know, doesn't work for long. Startups that grow and promote internally to fill such a role, may or may not work--depends on the individual. What's really needed is good alignment and balance of business goals and employee happiness. Two things which are both true: startups need to iterate fast to find that magic point; employees are a company's greatest asset. You can't forsake one for the other.

karmakaze 9y ago
> [0] Please don't comment about the voting on comments. It never does any good, and it makes boring reading. Despite the quoted item, I couldn't see how to understand the (incorrect?) use of downvoting comments as disagreement rather than to discourage unwanted behaviour which doesn't contribute to a discussion. In any case, a comment as to why is always helpful. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

chatmasta 9y ago

> Someone has a great new design they want to implement which is leagues better than what exists, and the existing design is just so awful. Only, it’s going to require some duct tape here and there, but that’s totally acceptable because overall it’s better. Until it becomes apparent that it’s mostly duct tape, but you’ve gone all-in on this and you can’t go back. > Solution: Start over. The sunken cost fallacy is real. You’ve made a mistake, and that’s ok, you can take those learnings and build something better. Don’t settle for chaos. Seems like a smart solution, and yet I almost never hear “throw it out and start over” as an option for dealing with unforeseen problems. Perhaps as programmers we should take some lessons from writers, who will often throw out all their work from the past day/week/month, because once it goes into production (a published book), you can’t change it. In software, you can change it, yes. But if it doesn’t add anything useful, complicates existing things, or will slow development in the future, there is a clear reason to just drop it and move onto the next approach. One way to make “just drop it” a more palatable option is to give yourself a grace period from the outset. Something like “if we can’t get this to work in a week, we’ll drop it and reevaluate.” This is when it helps to have at least two people (engineer + manager, or engineer x2) because it eliminates “developer pride” as a variable in decision making and holds someone accountable for making that decision after a week. As a manager, often the most important decisions are not what to build, but what not to build.

amriksohata 9y ago

In the UK in the last ten years the average salary for a senior developer has gone up from £35k to nearly £50k but for contractors, weirdly the average rate outside of London has stayed around £350 a day

methodover 9y ago

Loved this. And I agree with most of it. One thing I disagree with (and I know this puts me in the minority) is code review. Code review for trusted engineers is a waste of time. You're only going to find those bugs that are very hard to see. And the odds of you catching them in code review are very low. Also, if you're a kind of fast moving startup (like my company is) there's so much new code coming through that it is a serious slowdown to review it all. At least at the level where you'd need to if you're going to catch the things that the original author missed. I only make juniors and new hires do code reviews. I'll also ask for code reviews if an engineer is taking on a task that's totally new for them. But otherwise we've totally cut them out and been fine.

lovich 9y ago
Eh, half the benefit of code review on teams I've been on is just making the other engineers aware of what's going on. 75% of the code reviews are just a "good to go", the other 20% are questions about why a change was made that inform the other engineers about that particular business constraint, and the last 5% are actual issues. As you said, it's completely different for junior engineers where it ends up being more like 90% bugs/tech debt, but the code reviews aren't all useless
- nojvek 9y ago
  100% - Most code reviews are. Why are you doing this? please add a comment. Wait! this will break this other thing in some obscure way. Or hey! I built this other thing over here, let's re-use it.
ndh2 9y ago
In my opinion the main benefit of code review is diffusion of knowledge. It's kind of pointless to let new hires do reviews.
- methodover 9y ago
  What knowledge, specifically?

rustoo 9y ago

This post would still hold true if replace the phrase 'tech jobs' with just 'jobs' :) Such a wonderful article on all things wrong at the workplace these days.