27 ms·

The care and feeding of software engineers, or why engineers are grumpy (2012)

308 points by 1900jwatson 7y ago

UglyToad 7y ago
I hadn't seen this before but my god it's bang on every problem I experienced in my jobs and pretty much exactly what caused my burnout. I keep saying to people who ask what I'm doing next (currently taking a break) that my problem is I love coding but hate doing it as a job and this article has every reason why. Just to call attention to the first point about being a short order cook, this is precisely why scrum sucks and makes me so unhappy. You can't just give us work shorn of all context and use us as assembly line workers. Unless you're giving your developers full domain knowledge and involving them at every stage of the process you're wasting talent and money and your company probably sucks to work at.
- lobster45 7y ago
  Scrum is a way for managers to think they are doing a good job managing, but in fact are micromanaging. For every project, my manager wants a daily scrum. No really efficient
  - fffernan 7y ago
    I never dictate process to my teams, but then when i see them floundering around. "Maybe you should have a daily?" Then 2 weeks later "We had this great idea! We are going to meet daily!". If a manager is involved in Scrum its not really scrum...
    - WWLink 7y ago
      I kinda hate dailies.
      - gtirloni 7y ago
        Same. I've never seen a daily that didn't devolve into busyness reports. Sure, with proper scrum master I'm sure it works well but that's not my average experience.
      - rawoke083600 7y ago
        i really hate scrum. Makes me feel like a shoe production line worker. With many fallacies... like any team member can/should be able to work on any ticket. And dont get me started on all the meetings !
- sz4kerto 7y ago
  Scrum is not about context. You might or might not have context with or without scrum. Agile development doesn't work without context anyway.
  - closeparen 7y ago
    Consider: - Stories in the backlog are unassigned and should be executable by anyone. - If you finish your assigned stories early, you’re expected to pick off the top of the team’s stack rank, not your own agenda. There are project management approaches that involve making individuals responsible for large, coherent wholes. I’m fortunate to be on this kind of team now. But despite daily standup and biweekly sprint planning, it is not Scrum. Scrum explicitly trades off context and domain expertise for fungibility and cross-pollination.
- jlarocco 7y ago
  > I keep saying to people who ask what I'm doing next (currently taking a break) that my problem is I love coding but hate doing it as a job and this article has every reason why. I used to feel this way, but then I realized it's not useful. You're not going to change anything, and nobody's going to feel sorry for you because most people spend their whole day at work doing things they don't want to do. And I mean in general, not just software jobs. Work to pay the bills, and if you want to write code for fun do it outside of work on your own terms. If you want to enjoy work then start your own company. If you're working for somebody else it's always going to mean doing things you don't want to do sometimes.
  - shrimp_emoji 7y ago
    >If you're working for somebody else it's always going to mean doing things you don't want to do sometimes. Horrible things, things you're ashamed of, with horrible, antique tools. Try to change what you can (it's hard not to try), but otherwise play the detached mercenary and vote for the administration likeliest to implement UBI.
    - Mountain_Skies 7y ago
      Is the administration most like to implement UBI also the administration most likely to reduce regulations that dictate how you must conduct your business?
    - robocat 7y ago
      >>If you're working for somebody else it's always going to mean doing things you don't want to do sometimes. > Horrible things, things you're ashamed of, with horrible, antique tools. And when you own your own company, you use horrible tools and create ugly technical debt... But now the shame is personal because you can't easily blame someone else.
      - Aeolun 7y ago
        I don’t see why you would ever do that. It’s not like the horrible antiquated tools work any better than the modern ones.
- stephenboyd 7y ago
  The solution is to have the engineers make the engineering plan. It leads to a more effective and enjoyable plan and execution.
CM30 7y ago
Amen to this article. The way software engineers (and coders in general) are treated like assembly line workers is ridiculous. That said, I think one additional issue the field has is that there's a reluctance in companies to tell the customer/client that they're wrong/they can't have what they want if it's unrealistic to deliver that. Issues like the whole design changing because of constantly shifting requirements, massive levels of feature creep/scope creep, etc could in many ways be fixed if management said no. If they said that the customer/client couldn't get everything redone from scratch without extending the deadline or paying more. Etc.
- eeZah7Ux 7y ago
  > The way software engineers (and coders in general) are treated like assembly line workers is ridiculous. It's a trick to keep salaries from raising.
- odiroot 7y ago
  > Amen to this article. The way software engineers (and coders in general) are treated like assembly line workers is ridiculous. And it's still not so bad in the anglophone world. In some European countries engineers are considered a necessary evil that cuts into the bottom line. In many Asian countries (AFAIK) engineers are only treated as a cost centre, regularly overworked and underpaid. None of this SV or London splendour or special benefits.
  - walshemj 7y ago
    Unusual to hear engineers in the UK has having a splendid life :-)
    - odiroot 7y ago
      From what my friends tell me it's still better than continental EU.
sysbin 7y ago
Sometimes I wonder if I picked the wrong career from just viewing how analyzed this field happens to be. Every year a blog post I see about how to make things better or what's wrong and needing to change things up. I've never seen these constant blog posts on management & burn out for other high paying professions. I'm starting to wonder if programmers are just being psychologically manipulated every year to decrease the value of the skill and so companies can get more out of their money.
- hombre_fatal 7y ago
  I'm paid a lot and I work remotely from a beach. If I don't like my job, I can easily find another that I do like. Not too many other professions can say that. None of the doctors in my family can. Though at least they are saving lives, something else most professions can't say they do. :) We are lucky this field is so lucrative, especially in the US. Let's enjoy it while it lasts.
  - zzzcpan 7y ago
    > I'm paid a lot and I work remotely from a beach. If I don't like my job, I can easily find another that I do like. > Not too many other professions can say that. Software engineers can't say that, if that's what you are implying. I don't know who can actually, which profession is so lucrative and with so little supply of professionals, that finding a well payed remote job that you like is even a possibility?
    - _vertigo 7y ago
      Good software engineers in the United States absolutely can say that. Remote work typically pays less than work in high CoL areas but it still pays well. Additionally there are a lot of jobs out there. Personally I know that if I quit tomorrow I could easily have a job in less than a month. This isn’t going to be true in every area but it is absolutely true in the Bay Area currently.
      - turk73 7y ago
NikolaeVarius 7y ago
I dont understand why this article is specific to software engineers. This could be applied to a majority of white collar professions
- username90 7y ago
  Software engineer is the most common job requiring significant amounts of technical creativity. That makes it different from most white collar professions, and means you can't manage them in the same way you manage for example a group of accountants. Note I am not saying that accounting doesn't requires significant skill, just that for example it is a lot easier to get an accountant what he needs to do his job than to get a software engineer what he needs to do his job.
- Discombulator 7y ago
  The easiest answer is that HN is frequented by many people whose main (and often only) job activity is software development, so they/we think that our plight is special. I wonder if there is some hidden irony, because it appears to me that we sometimes assume that everyone else has a simple and straightforward job that we could probably automate.
  - balfirevic 7y ago
    > The easiest answer is that HN is frequented by many people whose main (and often only) job activity is software development, so they/we think that our plight is special. That's unfair (and untrue generally). The article is about software developers because it is written by someone who knows about software development. Does it also apply to civil engineers? Maybe, but I wouldn't know.
- deleted 7y ago
  [deleted]
- yomly 7y ago
  A while back I quizzed a doctor friend about working conditions in a hospital and found the relationship between doctors and hospital managers to be highly analogous to software. Interestingly the most successful hospital managers tended to be ex-doctors but it was hard to convince doctors to move into management. The heart of the issue is probably something surrounding trying to "manage" things according to some management principles when you don't understand the domain/skills of the people you are trying to manage. The more different it is to your career experience, the harder it probably is.
paranoiac 7y ago
[deleted]
- helij 7y ago
  Exactly the same here. I just quit my job because if this actually + commute. It just so happens that this time I didn't allow myself to become burnout. Which is progess I guess. Hope you solve your issue quickly. I know we tell ourselves this and that reason not to quit but sometimes there are two paths - either work against yourself or quit. Not sure if I know the answer here, sadly.
  - paranoiac 7y ago
    [deleted]
    - WrtCdEvrydy 7y ago
      Just don't care. Next time someone asks for something that is a fire ask them to tell the next person in line they're not that important.
ledauphin 7y ago
One thing this essay doesn't weave together, despite bringing up a lot of the threads, is that timelines for upcoming work are often estimated based on the (unrealistic) assumption that "you're going to leave me alone for long enough to get it done", which never happens. Instead, days get filled with discussions about future work, rehashes of previous discussions, identifying the bugs that junior developers have written, trying to convince management that the latest customer complaint has more to do with the fundamental laws of physics (e.g., network bandwidth limitations) rather than any actual issues with the software, etc... All of these are part of the job, but the conception of developers as "builders" worsens the issue because management does fundamentally believe that we spend most of our time "coding" when that couldn't be farther from the truth. And since we also want to imagine our days as filled with productive programming, we feed right back into the lie.
- PretzelFisch 7y ago
  I tell people now the estimate is for a week of work but I am coding 20% of the day...
  - Buttons840 7y ago
    ... and what they hear is "I promise it will be done by next week".
    - pfranz 7y ago
      It just depends on where and how you want to spend your time. I've "micro-managed" myself to prove the point. I gave them that estimate up front--told them this was assuming I had dedicated time to work. After a week or two I went back at them with how much time I had spent, how far along, and if I was above/below my estimate. Only then did they push to clear my schedule so I could get the hours in. The problem is that is a huge time-suck and they don't really care about the minutiae either. For me the whole goal is to keep the responsibilities clear and unnecessary communication to a minimum and I feel like that's done by building trust and being clear.
- 7y ago
alexfromapex 7y ago
This is so dead accurate. I would’ve lead with the second section or maybe reduced the first section to just the last paragraph but I have had these exact thoughts so many times.
mattwad 7y ago
It goes both ways. I've met engineers that want to be told what to do. I think they just looked at their role as "a job" which is fine. There's also people that are really interested in their work and should be included in the design process.
- cpitman 7y ago
  In consulting, I run into this type of engineer pretty often. And these engineers often work at companies that are scared of being disrupted. So my work in "Digital Transformation" is a two part challenge of teaching management to think of their IT department as a source of creative energy and not bricklayers, while trying to get the engineers out of the mindset of bricklayers themselves after many years of being shoehorned. It is not easy.
  - arbitrary_name 7y ago
    Very interested in this topic, as I work in IT and analytics org redesigns and tech strategy. If you have some content or thinking you'd like to share, it would be appreciated!
  - sk5t 7y ago
    Are you saying part of your job is to solve learned helplessness in the software engineering workplace? Are you effective?
  - to11mtm 7y ago
    > So my work in "Digital Transformation" is a two part challenge of teaching management to think of their IT department as a source of creative energy and not bricklayers, while trying to get the engineers out of the mindset of bricklayers themselves after many years of being shoehorned. You're doing the work of a higher order function there. You have my thanks. I've worked in environments where this type of change has been attempted. It's not easy and does run the risk of running VERY awry.
    - braindouche 7y ago
itronitron 7y ago
Years ago I heard about one of the main rules in improv which is that you can never say 'no' because it shuts down the creative potential in the performance. I took that to heart and applied it to work, whenever I wanted to scream NO at someone I offered instead to try it out and see what we could accomplish. Ninety percent of the time after further discussion it turned out they were asking for something entirely reasonable, the other 10% of the time there was either a compromise available or big money on the table. Worth noting that as I stopped saying no I also stopped feeling treated like an assembly line worker.
- fenwick67 7y ago
  I also try to do this at work, with the exception of ethical/moral and interpersonal stuff. Don't "yes and" into harassing someone, or into your drunk boss's passenger seat.
- blablabla123 7y ago
  I can relate to this a lot. Probably the reason of saying NO most often is the fear of bad things that could happen. On the other hand, if people spent less time discussing things and rather iterated on working (!) software, it would be less of a problem. In any case, I think engineers should in general do more creators work and product people should focus on keeping the business alive. Indeed there must be people that know the market, the business implications and the competition.
  - splittingTimes 7y ago
    I today agree, that devs being part of the creative process and not being drones leads to more happiness and has a lot of upside: they bring new ideas to the table, are more invested in the solution and feel owner ship -> quality of outcome is better. However, in my experience working on a big product with multiple teams, the main problems with devs getting creative is (a) the consistency of the user experience suffers badly (b) the overall architecture erodes as everybody builds particular solutions fitting their specific problem I am not sure what the best way is to reconcile Dev happiness and (a,b) in this context.
amenod 7y ago
> This flaw presents itself in a number of ways. The most frequent is in time estimates. Almost every engineer I know chronically underestimates how long it will take to complete a task or series of tasks. Only the very best are able to give and meet accurate time estimates while the rest are sometimes off by a factor of two or more. What is interesting is that we seem to be _much_ more accurate when estimating how much time a colleague will need to finish the task. So the solution is simple: when deciding on an estimate for yourself, try picturing someone else (less skilled preferably) doing the job. The result is surprisingly accurate, at least in my experience. :)
- bsder 7y ago
  Most engineers who have been doing it for more than 5 years generally can give estimates that are bang on. The problem is that management NEVER accepts that estimate. Ever. They want to "negotiate". The problem is that they don't want to adjust features or scope--they don't really want to negotiate. What they want is a better number without changing anything--they're playing "schedule chicken" instead or negotiating. Sadly, most engineers will feed into "schedule chicken" because they can almost always identify a group that will take longer than they will and so will get the blame for the schedule. And allowing another group to take the blame for the schedule is easier than arguing with your direct manager. The only engineers who won't play "schedule chicken" are the ones in the group that is going to take the longest. Those engineers know that they're going to get the blame and they're going to fight like crazy up front. (Side note: Nothing is more satisfying than being in the group that is supposed to take the blame and instead delivers on time. It causes complete political pandemonium. You still want to have your resume already being circulated outside the company, but it is incredibly satisfying to watch all the people who have been hassling you for months all turn on each other to shift blame.) I have only had one manager who listened because his job was on the line, too. When he said: "Look, the deadline isn't negotiable. We have something completed by date X or we're ALL basically fired." he actually listened when I said "This is the list of features and how I prioritize them. Here is the line for what we can get done by date X. You can have a feature below that line by swapping it for one above that line--but you have to make that swap TODAY. If you want that swap in 3 months, it costs you two features above that line." We delivered a week ahead of time. Funny how schedules work out just fine when management is actually on the hook, too.
progman32 7y ago
This rings true, and will be useful to introspect and more clearly explain concerns to colleagues. Apart from the short article[1] linked from the submission, are there similar pieces written from the POV of a manager or designer? Aside: Pretty sure most managers at my job already understand most of what this article is saying. I count my lucky stars, and I'll be sure to remind them that this is a huge reason why a lot of us stick around. Just as the article reminds us to recognize the engineers, we must also recognize when i.e. managers do something positive for their team. Also, on thanking engineers: If you see an engineer do something to help other engineers, recognize them or, better, help them. It really stings when, say, you spend a frustrating afternoon debugging obtuse test scaffolding code that's been affecting multiple teams, only to get nothing beyond a quick "looks good" review. [1] The link is broken but there appears to be a copy at https://library.gv.com/how-designers-and-engineers-can-play-nice-and-still-run-with-scissors-8df20e65c2c1 https://library.gv.com/how-designers-and-engineers-can-play-...
d23 7y ago
“Product managers are interesting people. Their ideas and capacity for understanding markets are impressive.” Citation needed.
- nickthemagicman 7y ago
  Agreed. This absolutely needs multiple citations.
tracer4201 7y ago
> This is one of the top things that make engineers grumpy: constantly shifting priorities. Author hits the nail on the head. I was on a team that shifted priorities just about every week - and not really the team but really management. Every decision was "reactive" to something someone said - that "someone" who doesn't really know that much, doesn't have that much power, etc., but management is convinced they'll look good if they can satisfy this one person or group of people, regardless of whether the outcome provides any true value. The manager was a great guy, but he over-indexed in the wrong things and spent too much effort optimizing purely for "optics". I realized I didn't see value in my output (nor my team's). I wasn't enjoying my work, and I really wasn't learning anything I really care for. The things I was learning had more to do with work politics and optics. So I left. And I took a vacation. :D Life is short. If you're going to work 60+ hours a week, at least find something that helps you grow in some way and/or that you find fulfilling. Unfortunately not everyone has that luxury, but if you do, only you can improve your situation.
unnouinceput 7y ago
Quote 1: "You need to work somewhere that appreciates your insights into the product as well as your ability to build it." And that's why I love to be a freelancer - clients need solutions to problems, they don't really care about design implementations/programming language/database, and they love every bit of creativity that drives costs down. I have clients that say on daily basis they love me, as they got one or more wrong implementations initially because "my partner/rival/uncle/god from heaven told me this is the way to do it" and when I propose something simpler & cheaper they marvel. Quote 2: "As ironic as it may sound, a lot of companies hire software engineers and then don’t let them actually code. Instead, their days are filled with useless meetings that inhibit productivity." Oh boy, I loved my time on big companies, I learned a lot but this 2nd quote hits me in the gut. Requirement meetings, regression test meetings, project status meetings, fill this standard Word document with details, fill that Excel document with metrics etc etc etc - I freaking hated them all. Sure, I learned about importance of this and that but dudes: let. me. code!! Siemens was the worse of them all, I suspect only 10% of the time I worked there was coding, rest was everything of the above.
- growlist 7y ago
  > Requirement meetings, regression test meetings, project status meetings, fill this standard Word document with details, fill that Excel document with metrics etc etc etc ...most of which never gets used for anything that contributes to the bottom line, and exists merely to enable bureaucrats to maintain a facade of doing Really Important Work
  - unnouinceput 7y ago
    It's not like that, they get used, and in most important way when you get involved with others: CYA (cover your ass). You see, when you are that time called annual performance review, these are the most important thing for your team leader/project manager/group leader, you know those who will decide to give you a Xmas bonus or bump your pay with 1%, to use to prove you don't deserve any of bonus/bump because you are full of mistakes on said documents. And if you do get any bonus/bump is shown like they make you a huge favor with the promise that you need in the future to become even more of a spineless monkey. Which is why currently we have this situation where coders jump ship at slightest increase from rival, because any loyalty that was embedded in us by our parents went out the window when we dealt with above situations.
bonoboTP 7y ago
Many problems with this attitude. First, just let go. You're building something for someone else, and making money for them. Treating it as your own "child" and being so psychologically invested will do you no good. In the grand scheme of things you're not "changing the world" with that new photo app or enterprise CRUD plug-in. Which ties in to the next point. Have a life outside work. Don't let work define you and be your only claim to personal value. It's insane that American programmers put up with so little free time. They want you on call? Then pay for every on call night and weekend. Anything less than 20-25 days off per year seems madness from Europe. And that leads to the next point. As the TFA says, naive, enthusiastic devs are often not motivated by money, but the joy of creating and they like to feel valued and thanked. TFA suggests giving awards and thanks and bullshit like that. No! The only appreciation a boss can give towards their employee is money (bonuses and salary increases). Everything else is manipulation. I don't care that you are super non-greedy good-person who doesn't care about money etc. It doesn't matter. What matters is your boss does care about it. You see, talk is cheap. I can print you all the award you want and will laugh behind your back what a loser you are. If you don't want the money then spend it for charity or frame the Benjamins and hang them above your bed. Or give it to your local homeless guy or your grandma. I don't care, but in business (not in personal relations), respect is money and money is respect. The earlier you learn it, the better. Nobody will take you seriously otherwise and you'll be seen as childishly naive until you understand money beyond it being the thing for the douche-y suit types.
- deleted 7y ago
  [deleted]
feikname 7y ago
> Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked. Totally off-topic to this article: I've seen more and more the use of she as a demonsrative pronoum rather than a personal one (e.g. moon as her) and as actually a gender-neutral personal pronoum for people and animals, specially for generalized cases. Is this "valid" formal english or is it a trend? Also, if anyone knows the name of using "her" like this please tell me, I'd like to know more about this.
- zdragnar 7y ago
  Without wading too deeply into the topic, I can say that I have only really seen it as a trend among developer documentation and writing, as a means of fostering I gender inclusiveness. I have yet to really see this in other writing amongst stereotypically gendered professional writing. As for non-people, it is a bit more common; the most obvious one in English I can think of is both boats and open waters.
- trobertson 7y ago
  It's a response to the use of "he" as the default pronoun. "he" is gendered and basically everywhere, which means that many people consider its use sexist. Their response is to use "she" in an effort to swing the gendered-pronoun usage towards 50/50. Other people choose to use the gender-neutral "they", which gives grammar-focused people an mild aneurysm.
  - _s 7y ago
    Is that because “they” refers generally to a plural? I’ve started using it to refer to singular people as a neutral reference but haven’t had anyone attempt to correct it.
    - linuxftw 7y ago
      It is acceptable to use 'they' as singular when referring to 'a person.' Works: "When a person reads, they learn" Doesn't work: "When Jim reads, they learn" It also works for other non-proper nouns like "When a knight enters the room, they kneel". I think this is mostly an artifact of implying "When knights enter the room, they kneel." I feel like this also works: "When the author wrote x, they were really saying y". I'm sure there's some explanation for it, but it's generally okay to use 'they' in the singular and anyone that disagrees is some snobbish weirdo. It clearly conveys what one means which makes it suitable for use, IMO.
awinter-py 7y ago
> They also have a tendency to believe that their ideas are fully-formed when, in fact, there are holes so large that trains could fit through Really important thing to be aware of, not specifically for PMs but for everyone. Have interviewed 20+ managers this year on exactly this topic. My favorite answer: product owners should collaboratively identify broad goals for a feature or product, make sure everyone is on the same page (sometimes by compromising on goals), and not solidify any plans until the goal phase is done, lest SMEs mutiny.
turk73 7y ago
"Engineer burnout is unique because we are used to powering through it. When burnout gets bad enough, we leave, looking for relief. What’s more, engineers will probably never tell you that they’re approaching that point; we’re too proud for that." I don't tell you because why would I show my cards like that? You don't deserve to know what is going on with me because you treat me like a whore even though I'm not a whore. Your business processes are whack, your so-called "agile" is nothing but impressment. It is a wonder anyone wants these damn jobs. I currently have a product owner who doesn't understand what streaming data in Kafka means. Not a single clue! We have a bunch of different topics where data arrives out of order and asynchronously and we have to join that data, but for some reason she thinks it is like a csv file that I can just go read and count every single line, etc. Drives me batshit. And that's the other thing--half-brain people who don't know how to code or even be "technical" people why are they in these jobs in the first place? Go be a cashier at Macy's, please!
viburnum 7y ago
Grumpiness is good, actually. There are worse moods.
winrid 7y ago
Taking advantage of developer's creative side is one thing I know my company needs to do better. Luckily I'm in a position to fix this. Good reminder. :)
ncmncm 7y ago
To me the key line in the whole essay was: It’s difficult to get into a good flow while coding if you know you have a meeting coming up in an hour or two One meeting in the day is enough to ruin a whole day for coding. All you can do for the rest of that day is putter. Projects do need a certain amount of puttering, but when they need it is not the day of the meeting.
- geewee 7y ago
  I find that putting the daily standup right after or before lunch, pretty easily fixes this problem (assuming the team eats lunch together) - there's no extra time wasted, as you would have been interrupted anyways.
  - peterkelly 7y ago
    I find that removing the daily standup altogether fixes the problem even more effectively.
  - sojournerc 7y ago
    It's not just the time interruption though, it's the mental interruption of thinking about other parts of the project, business, etc, etc, that a stand up creates. If I'm in the zone and go to lunch, I'll keep churning on the problem in my head, and might even have a solution when I'm back at keyboard. If I have a meeting before or after lunch, that context is gone
    - ncmncm 7y ago
      Exactly: sometimes, when it gets particularly intense, I go take a nap (which I can) and come back with new clarity and a better approach.
- solidasparagus 7y ago
  I'm sorry, but if one meeting ruins the productivity of your entire day, I think something is very wrong. If you truly find that you can't be productive given a 3 hour window, you might need to reevaluate your approach to work and come up with a better system.
thayne 7y ago
> We have a tragic flaw and that flaw is that we overestimate our knowledge and abilities... The most frequent is in time estimates. I won't dispute that engineers overestimate knowledge and abilities sometimes, or that estimates are wrong more often than not. However, most engineers I know are well aware that _any_ estimate they give will be wrong, but do the best with the knowledge they have because the PM needs some kind of estimate in order to plan. Estimates aren't low because we don't take into account our lack of knowledge, they are low (or sometimes actually high) because we don't even know how much we don't know.
- Vinnl 7y ago
  I don't really get that. Why would someone need an estimate if the estimate is wrong anyway - what use it is. Then if I'm forced to give an estimate, I usually add an order of magnitude precisely because I know there's a lot I don't know yet, and the worst and best cases of underpromising and over-delivering are better than vice versa. Yet many people's intuitions (also engineers') appear to disagree with that.
  - Tempest1981 7y ago
    For years, I felt guilty (or was made to feel guilty) for giving an accurate/realistic estimate. Mostly at startups, where you feel, everyday, that the company is at risk of failing. It's better to give a range of estimates - best case to worst case. Although managers may only hear the best case.
    - Vinnl 7y ago
      Sure, but especially when I'm made to feel guilty, my answer is always: the estimate I give does not influence how quickly the work is going to get done, so feel free to tell yourself that it will take half the time if that makes you feel better. I want to make it as explicit as possible that, if a manager only hears the best case, that's of their own volition.
pedrorijo91 7y ago
> Yet, you’ll rarely find software engineers complaining about long hours or being woken up because of a production issue. The software is our baby, and we like to care for it as such. That means if it needs feeding in the middle of the night, we do it. If it needs extra care over the weekend, we do that too, all with a smile because our creation is growing. We need to stop this! We are promoting unhealthy extra hours. We are making it like it's ok to expect/ask developers to work overnight and weekends. Work-life balance is not just a cliché, we need to incentivise developers to have a real life outside of work > I was once about to leave my place with a date when the office called because of a production issue. She sat and waited patiently for an hour while I tried frantically to fix the issue before she ultimately took off (I couldn’t blame her), leaving me to my work and my coworkers in IRC sharing my misery. is this company really so dependent of a single developer? unless it's a startup with 3 employees it sounds like a problem. Or maybe the developer thinks it's the only one able to save the day?

308 points by 1900jwatson 7y ago

I hadn't seen this before but my god it's bang on every problem I experienced in my jobs and pretty much exactly what caused my burnout. I keep saying to people who ask what I'm doing next (currently taking a break) that my problem is I love coding but hate doing it as a job and this article has every reason why. Just to call attention to the first point about being a short order cook, this is precisely why scrum sucks and makes me so unhappy. You can't just give us work shorn of all context and use us as assembly line workers. Unless you're giving your developers full domain knowledge and involving them at every stage of the process you're wasting talent and money and your company probably sucks to work at.

lobster45 7y ago
Scrum is a way for managers to think they are doing a good job managing, but in fact are micromanaging. For every project, my manager wants a daily scrum. No really efficient
- fffernan 7y ago
  I never dictate process to my teams, but then when i see them floundering around. "Maybe you should have a daily?" Then 2 weeks later "We had this great idea! We are going to meet daily!". If a manager is involved in Scrum its not really scrum...
  - WWLink 7y ago
    I kinda hate dailies.
    - gtirloni 7y ago
      Same. I've never seen a daily that didn't devolve into busyness reports. Sure, with proper scrum master I'm sure it works well but that's not my average experience.
    - rawoke083600 7y ago
      i really hate scrum. Makes me feel like a shoe production line worker. With many fallacies... like any team member can/should be able to work on any ticket. And dont get me started on all the meetings !
sz4kerto 7y ago
Scrum is not about context. You might or might not have context with or without scrum. Agile development doesn't work without context anyway.
- closeparen 7y ago
  Consider: - Stories in the backlog are unassigned and should be executable by anyone. - If you finish your assigned stories early, you’re expected to pick off the top of the team’s stack rank, not your own agenda. There are project management approaches that involve making individuals responsible for large, coherent wholes. I’m fortunate to be on this kind of team now. But despite daily standup and biweekly sprint planning, it is not Scrum. Scrum explicitly trades off context and domain expertise for fungibility and cross-pollination.
jlarocco 7y ago
> I keep saying to people who ask what I'm doing next (currently taking a break) that my problem is I love coding but hate doing it as a job and this article has every reason why. I used to feel this way, but then I realized it's not useful. You're not going to change anything, and nobody's going to feel sorry for you because most people spend their whole day at work doing things they don't want to do. And I mean in general, not just software jobs. Work to pay the bills, and if you want to write code for fun do it outside of work on your own terms. If you want to enjoy work then start your own company. If you're working for somebody else it's always going to mean doing things you don't want to do sometimes.
- shrimp_emoji 7y ago
  >If you're working for somebody else it's always going to mean doing things you don't want to do sometimes. Horrible things, things you're ashamed of, with horrible, antique tools. Try to change what you can (it's hard not to try), but otherwise play the detached mercenary and vote for the administration likeliest to implement UBI.
  - Mountain_Skies 7y ago
    Is the administration most like to implement UBI also the administration most likely to reduce regulations that dictate how you must conduct your business?
  - robocat 7y ago
    >>If you're working for somebody else it's always going to mean doing things you don't want to do sometimes. > Horrible things, things you're ashamed of, with horrible, antique tools. And when you own your own company, you use horrible tools and create ugly technical debt... But now the shame is personal because you can't easily blame someone else.
    - Aeolun 7y ago
      I don’t see why you would ever do that. It’s not like the horrible antiquated tools work any better than the modern ones.
stephenboyd 7y ago
The solution is to have the engineers make the engineering plan. It leads to a more effective and enjoyable plan and execution.

CM30 7y ago

Amen to this article. The way software engineers (and coders in general) are treated like assembly line workers is ridiculous. That said, I think one additional issue the field has is that there's a reluctance in companies to tell the customer/client that they're wrong/they can't have what they want if it's unrealistic to deliver that. Issues like the whole design changing because of constantly shifting requirements, massive levels of feature creep/scope creep, etc could in many ways be fixed if management said no. If they said that the customer/client couldn't get everything redone from scratch without extending the deadline or paying more. Etc.

eeZah7Ux 7y ago
> The way software engineers (and coders in general) are treated like assembly line workers is ridiculous. It's a trick to keep salaries from raising.
odiroot 7y ago
> Amen to this article. The way software engineers (and coders in general) are treated like assembly line workers is ridiculous. And it's still not so bad in the anglophone world. In some European countries engineers are considered a necessary evil that cuts into the bottom line. In many Asian countries (AFAIK) engineers are only treated as a cost centre, regularly overworked and underpaid. None of this SV or London splendour or special benefits.
- walshemj 7y ago
  Unusual to hear engineers in the UK has having a splendid life :-)
  - odiroot 7y ago
    From what my friends tell me it's still better than continental EU.

sysbin 7y ago

Sometimes I wonder if I picked the wrong career from just viewing how analyzed this field happens to be. Every year a blog post I see about how to make things better or what's wrong and needing to change things up. I've never seen these constant blog posts on management & burn out for other high paying professions. I'm starting to wonder if programmers are just being psychologically manipulated every year to decrease the value of the skill and so companies can get more out of their money.

hombre_fatal 7y ago
I'm paid a lot and I work remotely from a beach. If I don't like my job, I can easily find another that I do like. Not too many other professions can say that. None of the doctors in my family can. Though at least they are saving lives, something else most professions can't say they do. :) We are lucky this field is so lucrative, especially in the US. Let's enjoy it while it lasts.
- zzzcpan 7y ago
  > I'm paid a lot and I work remotely from a beach. If I don't like my job, I can easily find another that I do like. > Not too many other professions can say that. Software engineers can't say that, if that's what you are implying. I don't know who can actually, which profession is so lucrative and with so little supply of professionals, that finding a well payed remote job that you like is even a possibility?
  - _vertigo 7y ago
    Good software engineers in the United States absolutely can say that. Remote work typically pays less than work in high CoL areas but it still pays well. Additionally there are a lot of jobs out there. Personally I know that if I quit tomorrow I could easily have a job in less than a month. This isn’t going to be true in every area but it is absolutely true in the Bay Area currently.
    - turk73 7y ago

NikolaeVarius 7y ago

I dont understand why this article is specific to software engineers. This could be applied to a majority of white collar professions

username90 7y ago
Software engineer is the most common job requiring significant amounts of technical creativity. That makes it different from most white collar professions, and means you can't manage them in the same way you manage for example a group of accountants. Note I am not saying that accounting doesn't requires significant skill, just that for example it is a lot easier to get an accountant what he needs to do his job than to get a software engineer what he needs to do his job.
Discombulator 7y ago
The easiest answer is that HN is frequented by many people whose main (and often only) job activity is software development, so they/we think that our plight is special. I wonder if there is some hidden irony, because it appears to me that we sometimes assume that everyone else has a simple and straightforward job that we could probably automate.
- balfirevic 7y ago
  > The easiest answer is that HN is frequented by many people whose main (and often only) job activity is software development, so they/we think that our plight is special. That's unfair (and untrue generally). The article is about software developers because it is written by someone who knows about software development. Does it also apply to civil engineers? Maybe, but I wouldn't know.
deleted 7y ago
[deleted]
yomly 7y ago
A while back I quizzed a doctor friend about working conditions in a hospital and found the relationship between doctors and hospital managers to be highly analogous to software. Interestingly the most successful hospital managers tended to be ex-doctors but it was hard to convince doctors to move into management. The heart of the issue is probably something surrounding trying to "manage" things according to some management principles when you don't understand the domain/skills of the people you are trying to manage. The more different it is to your career experience, the harder it probably is.

paranoiac 7y ago

[deleted]

helij 7y ago
Exactly the same here. I just quit my job because if this actually + commute. It just so happens that this time I didn't allow myself to become burnout. Which is progess I guess. Hope you solve your issue quickly. I know we tell ourselves this and that reason not to quit but sometimes there are two paths - either work against yourself or quit. Not sure if I know the answer here, sadly.
- paranoiac 7y ago
  [deleted]
  - WrtCdEvrydy 7y ago
    Just don't care. Next time someone asks for something that is a fire ask them to tell the next person in line they're not that important.

ledauphin 7y ago

One thing this essay doesn't weave together, despite bringing up a lot of the threads, is that timelines for upcoming work are often estimated based on the (unrealistic) assumption that "you're going to leave me alone for long enough to get it done", which never happens. Instead, days get filled with discussions about future work, rehashes of previous discussions, identifying the bugs that junior developers have written, trying to convince management that the latest customer complaint has more to do with the fundamental laws of physics (e.g., network bandwidth limitations) rather than any actual issues with the software, etc... All of these are part of the job, but the conception of developers as "builders" worsens the issue because management does fundamentally believe that we spend most of our time "coding" when that couldn't be farther from the truth. And since we also want to imagine our days as filled with productive programming, we feed right back into the lie.

PretzelFisch 7y ago
I tell people now the estimate is for a week of work but I am coding 20% of the day...
- Buttons840 7y ago
  ... and what they hear is "I promise it will be done by next week".
  - pfranz 7y ago
    It just depends on where and how you want to spend your time. I've "micro-managed" myself to prove the point. I gave them that estimate up front--told them this was assuming I had dedicated time to work. After a week or two I went back at them with how much time I had spent, how far along, and if I was above/below my estimate. Only then did they push to clear my schedule so I could get the hours in. The problem is that is a huge time-suck and they don't really care about the minutiae either. For me the whole goal is to keep the responsibilities clear and unnecessary communication to a minimum and I feel like that's done by building trust and being clear.
7y ago

alexfromapex 7y ago

This is so dead accurate. I would’ve lead with the second section or maybe reduced the first section to just the last paragraph but I have had these exact thoughts so many times.

mattwad 7y ago

It goes both ways. I've met engineers that want to be told what to do. I think they just looked at their role as "a job" which is fine. There's also people that are really interested in their work and should be included in the design process.

cpitman 7y ago
In consulting, I run into this type of engineer pretty often. And these engineers often work at companies that are scared of being disrupted. So my work in "Digital Transformation" is a two part challenge of teaching management to think of their IT department as a source of creative energy and not bricklayers, while trying to get the engineers out of the mindset of bricklayers themselves after many years of being shoehorned. It is not easy.
- arbitrary_name 7y ago
  Very interested in this topic, as I work in IT and analytics org redesigns and tech strategy. If you have some content or thinking you'd like to share, it would be appreciated!
- sk5t 7y ago
  Are you saying part of your job is to solve learned helplessness in the software engineering workplace? Are you effective?
- to11mtm 7y ago
  > So my work in "Digital Transformation" is a two part challenge of teaching management to think of their IT department as a source of creative energy and not bricklayers, while trying to get the engineers out of the mindset of bricklayers themselves after many years of being shoehorned. You're doing the work of a higher order function there. You have my thanks. I've worked in environments where this type of change has been attempted. It's not easy and does run the risk of running VERY awry.
  - braindouche 7y ago

itronitron 7y ago

Years ago I heard about one of the main rules in improv which is that you can never say 'no' because it shuts down the creative potential in the performance. I took that to heart and applied it to work, whenever I wanted to scream NO at someone I offered instead to try it out and see what we could accomplish. Ninety percent of the time after further discussion it turned out they were asking for something entirely reasonable, the other 10% of the time there was either a compromise available or big money on the table. Worth noting that as I stopped saying no I also stopped feeling treated like an assembly line worker.

fenwick67 7y ago
I also try to do this at work, with the exception of ethical/moral and interpersonal stuff. Don't "yes and" into harassing someone, or into your drunk boss's passenger seat.
blablabla123 7y ago
I can relate to this a lot. Probably the reason of saying NO most often is the fear of bad things that could happen. On the other hand, if people spent less time discussing things and rather iterated on working (!) software, it would be less of a problem. In any case, I think engineers should in general do more creators work and product people should focus on keeping the business alive. Indeed there must be people that know the market, the business implications and the competition.
- splittingTimes 7y ago
  I today agree, that devs being part of the creative process and not being drones leads to more happiness and has a lot of upside: they bring new ideas to the table, are more invested in the solution and feel owner ship -> quality of outcome is better. However, in my experience working on a big product with multiple teams, the main problems with devs getting creative is (a) the consistency of the user experience suffers badly (b) the overall architecture erodes as everybody builds particular solutions fitting their specific problem I am not sure what the best way is to reconcile Dev happiness and (a,b) in this context.

amenod 7y ago

> This flaw presents itself in a number of ways. The most frequent is in time estimates. Almost every engineer I know chronically underestimates how long it will take to complete a task or series of tasks. Only the very best are able to give and meet accurate time estimates while the rest are sometimes off by a factor of two or more. What is interesting is that we seem to be _much_ more accurate when estimating how much time a colleague will need to finish the task. So the solution is simple: when deciding on an estimate for yourself, try picturing someone else (less skilled preferably) doing the job. The result is surprisingly accurate, at least in my experience. :)

bsder 7y ago
Most engineers who have been doing it for more than 5 years generally can give estimates that are bang on. The problem is that management NEVER accepts that estimate. Ever. They want to "negotiate". The problem is that they don't want to adjust features or scope--they don't really want to negotiate. What they want is a better number without changing anything--they're playing "schedule chicken" instead or negotiating. Sadly, most engineers will feed into "schedule chicken" because they can almost always identify a group that will take longer than they will and so will get the blame for the schedule. And allowing another group to take the blame for the schedule is easier than arguing with your direct manager. The only engineers who won't play "schedule chicken" are the ones in the group that is going to take the longest. Those engineers know that they're going to get the blame and they're going to fight like crazy up front. (Side note: Nothing is more satisfying than being in the group that is supposed to take the blame and instead delivers on time. It causes complete political pandemonium. You still want to have your resume already being circulated outside the company, but it is incredibly satisfying to watch all the people who have been hassling you for months all turn on each other to shift blame.) I have only had one manager who listened because his job was on the line, too. When he said: "Look, the deadline isn't negotiable. We have something completed by date X or we're ALL basically fired." he actually listened when I said "This is the list of features and how I prioritize them. Here is the line for what we can get done by date X. You can have a feature below that line by swapping it for one above that line--but you have to make that swap TODAY. If you want that swap in 3 months, it costs you two features above that line." We delivered a week ahead of time. Funny how schedules work out just fine when management is actually on the hook, too.

progman32 7y ago

This rings true, and will be useful to introspect and more clearly explain concerns to colleagues. Apart from the short article[1] linked from the submission, are there similar pieces written from the POV of a manager or designer? Aside: Pretty sure most managers at my job already understand most of what this article is saying. I count my lucky stars, and I'll be sure to remind them that this is a huge reason why a lot of us stick around. Just as the article reminds us to recognize the engineers, we must also recognize when i.e. managers do something positive for their team. Also, on thanking engineers: If you see an engineer do something to help other engineers, recognize them or, better, help them. It really stings when, say, you spend a frustrating afternoon debugging obtuse test scaffolding code that's been affecting multiple teams, only to get nothing beyond a quick "looks good" review. [1] The link is broken but there appears to be a copy at https://library.gv.com/how-designers-and-engineers-can-play-nice-and-still-run-with-scissors-8df20e65c2c1 https://library.gv.com/how-designers-and-engineers-can-play-...

d23 7y ago

“Product managers are interesting people. Their ideas and capacity for understanding markets are impressive.” Citation needed.

nickthemagicman 7y ago
Agreed. This absolutely needs multiple citations.

tracer4201 7y ago

> This is one of the top things that make engineers grumpy: constantly shifting priorities. Author hits the nail on the head. I was on a team that shifted priorities just about every week - and not really the team but really management. Every decision was "reactive" to something someone said - that "someone" who doesn't really know that much, doesn't have that much power, etc., but management is convinced they'll look good if they can satisfy this one person or group of people, regardless of whether the outcome provides any true value. The manager was a great guy, but he over-indexed in the wrong things and spent too much effort optimizing purely for "optics". I realized I didn't see value in my output (nor my team's). I wasn't enjoying my work, and I really wasn't learning anything I really care for. The things I was learning had more to do with work politics and optics. So I left. And I took a vacation. :D Life is short. If you're going to work 60+ hours a week, at least find something that helps you grow in some way and/or that you find fulfilling. Unfortunately not everyone has that luxury, but if you do, only you can improve your situation.

unnouinceput 7y ago

Quote 1: "You need to work somewhere that appreciates your insights into the product as well as your ability to build it." And that's why I love to be a freelancer - clients need solutions to problems, they don't really care about design implementations/programming language/database, and they love every bit of creativity that drives costs down. I have clients that say on daily basis they love me, as they got one or more wrong implementations initially because "my partner/rival/uncle/god from heaven told me this is the way to do it" and when I propose something simpler & cheaper they marvel. Quote 2: "As ironic as it may sound, a lot of companies hire software engineers and then don’t let them actually code. Instead, their days are filled with useless meetings that inhibit productivity." Oh boy, I loved my time on big companies, I learned a lot but this 2nd quote hits me in the gut. Requirement meetings, regression test meetings, project status meetings, fill this standard Word document with details, fill that Excel document with metrics etc etc etc - I freaking hated them all. Sure, I learned about importance of this and that but dudes: let. me. code!! Siemens was the worse of them all, I suspect only 10% of the time I worked there was coding, rest was everything of the above.

growlist 7y ago
> Requirement meetings, regression test meetings, project status meetings, fill this standard Word document with details, fill that Excel document with metrics etc etc etc ...most of which never gets used for anything that contributes to the bottom line, and exists merely to enable bureaucrats to maintain a facade of doing Really Important Work
- unnouinceput 7y ago
  It's not like that, they get used, and in most important way when you get involved with others: CYA (cover your ass). You see, when you are that time called annual performance review, these are the most important thing for your team leader/project manager/group leader, you know those who will decide to give you a Xmas bonus or bump your pay with 1%, to use to prove you don't deserve any of bonus/bump because you are full of mistakes on said documents. And if you do get any bonus/bump is shown like they make you a huge favor with the promise that you need in the future to become even more of a spineless monkey. Which is why currently we have this situation where coders jump ship at slightest increase from rival, because any loyalty that was embedded in us by our parents went out the window when we dealt with above situations.

bonoboTP 7y ago

Many problems with this attitude. First, just let go. You're building something for someone else, and making money for them. Treating it as your own "child" and being so psychologically invested will do you no good. In the grand scheme of things you're not "changing the world" with that new photo app or enterprise CRUD plug-in. Which ties in to the next point. Have a life outside work. Don't let work define you and be your only claim to personal value. It's insane that American programmers put up with so little free time. They want you on call? Then pay for every on call night and weekend. Anything less than 20-25 days off per year seems madness from Europe. And that leads to the next point. As the TFA says, naive, enthusiastic devs are often not motivated by money, but the joy of creating and they like to feel valued and thanked. TFA suggests giving awards and thanks and bullshit like that. No! The only appreciation a boss can give towards their employee is money (bonuses and salary increases). Everything else is manipulation. I don't care that you are super non-greedy good-person who doesn't care about money etc. It doesn't matter. What matters is your boss does care about it. You see, talk is cheap. I can print you all the award you want and will laugh behind your back what a loser you are. If you don't want the money then spend it for charity or frame the Benjamins and hang them above your bed. Or give it to your local homeless guy or your grandma. I don't care, but in business (not in personal relations), respect is money and money is respect. The earlier you learn it, the better. Nobody will take you seriously otherwise and you'll be seen as childishly naive until you understand money beyond it being the thing for the douche-y suit types.

deleted 7y ago
[deleted]

feikname 7y ago

> Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked. Totally off-topic to this article: I've seen more and more the use of she as a demonsrative pronoum rather than a personal one (e.g. moon as her) and as actually a gender-neutral personal pronoum for people and animals, specially for generalized cases. Is this "valid" formal english or is it a trend? Also, if anyone knows the name of using "her" like this please tell me, I'd like to know more about this.

zdragnar 7y ago
Without wading too deeply into the topic, I can say that I have only really seen it as a trend among developer documentation and writing, as a means of fostering I gender inclusiveness. I have yet to really see this in other writing amongst stereotypically gendered professional writing. As for non-people, it is a bit more common; the most obvious one in English I can think of is both boats and open waters.
trobertson 7y ago
It's a response to the use of "he" as the default pronoun. "he" is gendered and basically everywhere, which means that many people consider its use sexist. Their response is to use "she" in an effort to swing the gendered-pronoun usage towards 50/50. Other people choose to use the gender-neutral "they", which gives grammar-focused people an mild aneurysm.
- _s 7y ago
  Is that because “they” refers generally to a plural? I’ve started using it to refer to singular people as a neutral reference but haven’t had anyone attempt to correct it.
  - linuxftw 7y ago
    It is acceptable to use 'they' as singular when referring to 'a person.' Works: "When a person reads, they learn" Doesn't work: "When Jim reads, they learn" It also works for other non-proper nouns like "When a knight enters the room, they kneel". I think this is mostly an artifact of implying "When knights enter the room, they kneel." I feel like this also works: "When the author wrote x, they were really saying y". I'm sure there's some explanation for it, but it's generally okay to use 'they' in the singular and anyone that disagrees is some snobbish weirdo. It clearly conveys what one means which makes it suitable for use, IMO.

awinter-py 7y ago

> They also have a tendency to believe that their ideas are fully-formed when, in fact, there are holes so large that trains could fit through Really important thing to be aware of, not specifically for PMs but for everyone. Have interviewed 20+ managers this year on exactly this topic. My favorite answer: product owners should collaboratively identify broad goals for a feature or product, make sure everyone is on the same page (sometimes by compromising on goals), and not solidify any plans until the goal phase is done, lest SMEs mutiny.

turk73 7y ago

"Engineer burnout is unique because we are used to powering through it. When burnout gets bad enough, we leave, looking for relief. What’s more, engineers will probably never tell you that they’re approaching that point; we’re too proud for that." I don't tell you because why would I show my cards like that? You don't deserve to know what is going on with me because you treat me like a whore even though I'm not a whore. Your business processes are whack, your so-called "agile" is nothing but impressment. It is a wonder anyone wants these damn jobs. I currently have a product owner who doesn't understand what streaming data in Kafka means. Not a single clue! We have a bunch of different topics where data arrives out of order and asynchronously and we have to join that data, but for some reason she thinks it is like a csv file that I can just go read and count every single line, etc. Drives me batshit. And that's the other thing--half-brain people who don't know how to code or even be "technical" people why are they in these jobs in the first place? Go be a cashier at Macy's, please!

viburnum 7y ago

Grumpiness is good, actually. There are worse moods.

winrid 7y ago

Taking advantage of developer's creative side is one thing I know my company needs to do better. Luckily I'm in a position to fix this. Good reminder. :)

ncmncm 7y ago

To me the key line in the whole essay was: It’s difficult to get into a good flow while coding if you know you have a meeting coming up in an hour or two One meeting in the day is enough to ruin a whole day for coding. All you can do for the rest of that day is putter. Projects do need a certain amount of puttering, but when they need it is not the day of the meeting.

geewee 7y ago
I find that putting the daily standup right after or before lunch, pretty easily fixes this problem (assuming the team eats lunch together) - there's no extra time wasted, as you would have been interrupted anyways.
- peterkelly 7y ago
  I find that removing the daily standup altogether fixes the problem even more effectively.
- sojournerc 7y ago
  It's not just the time interruption though, it's the mental interruption of thinking about other parts of the project, business, etc, etc, that a stand up creates. If I'm in the zone and go to lunch, I'll keep churning on the problem in my head, and might even have a solution when I'm back at keyboard. If I have a meeting before or after lunch, that context is gone
  - ncmncm 7y ago
    Exactly: sometimes, when it gets particularly intense, I go take a nap (which I can) and come back with new clarity and a better approach.
solidasparagus 7y ago
I'm sorry, but if one meeting ruins the productivity of your entire day, I think something is very wrong. If you truly find that you can't be productive given a 3 hour window, you might need to reevaluate your approach to work and come up with a better system.

thayne 7y ago

> We have a tragic flaw and that flaw is that we overestimate our knowledge and abilities... The most frequent is in time estimates. I won't dispute that engineers overestimate knowledge and abilities sometimes, or that estimates are wrong more often than not. However, most engineers I know are well aware that _any_ estimate they give will be wrong, but do the best with the knowledge they have because the PM needs some kind of estimate in order to plan. Estimates aren't low because we don't take into account our lack of knowledge, they are low (or sometimes actually high) because we don't even know how much we don't know.

Vinnl 7y ago
I don't really get that. Why would someone need an estimate if the estimate is wrong anyway - what use it is. Then if I'm forced to give an estimate, I usually add an order of magnitude precisely because I know there's a lot I don't know yet, and the worst and best cases of underpromising and over-delivering are better than vice versa. Yet many people's intuitions (also engineers') appear to disagree with that.
- Tempest1981 7y ago
  For years, I felt guilty (or was made to feel guilty) for giving an accurate/realistic estimate. Mostly at startups, where you feel, everyday, that the company is at risk of failing. It's better to give a range of estimates - best case to worst case. Although managers may only hear the best case.
  - Vinnl 7y ago
    Sure, but especially when I'm made to feel guilty, my answer is always: the estimate I give does not influence how quickly the work is going to get done, so feel free to tell yourself that it will take half the time if that makes you feel better. I want to make it as explicit as possible that, if a manager only hears the best case, that's of their own volition.

pedrorijo91 7y ago

> Yet, you’ll rarely find software engineers complaining about long hours or being woken up because of a production issue. The software is our baby, and we like to care for it as such. That means if it needs feeding in the middle of the night, we do it. If it needs extra care over the weekend, we do that too, all with a smile because our creation is growing. We need to stop this! We are promoting unhealthy extra hours. We are making it like it's ok to expect/ask developers to work overnight and weekends. Work-life balance is not just a cliché, we need to incentivise developers to have a real life outside of work > I was once about to leave my place with a date when the office called because of a production issue. She sat and waited patiently for an hour while I tried frantically to fix the issue before she ultimately took off (I couldn’t blame her), leaving me to my work and my coworkers in IRC sharing my misery. is this company really so dependent of a single developer? unless it's a startup with 3 employees it sounds like a problem. Or maybe the developer thinks it's the only one able to save the day?