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.
You can solve that problem honestly or not so honestly. I've worked in places where everyone knew to pad their time without telling the non-dev in the room. I've been happier with also estimating the ratio of time you spend doing tasks. Someone more senior should intend to spend less than 100% of their time on those tasks.
Both of those work better than ignoring overhead or refusal to estimate, imho.
I thought the article broke down those things rather well. It talks about how detrimental context shifting is, shifting priorities. In the part about how poor time estimates are, "No time is put in for meetings to go over requirements and make changes," not time is accounted for bugs, or the learning part about solving a problem.
Measuring and optimizing bottlenecks is a core agile idea.
My team's process is to estimate and track dev non-dev time with our other sprint metrics at dev-day granularity. ie last sprint I estimated 2 non-dev days for product / design discussions, factoring in the meetings/doc writing/cost of mental randomization/etc. Planning and retrospective provide opportunities to reflect on reducing communication overhead within the team, and the metric is valuable for pushing back on top-down management-mandated overhead.
Yes. And the problem of giving more realistic planning is that management will say: "but [insert name of random coworker] can do it in half of that time!" Of course that coworker is dealing with the same problems as you do.
It may not be so much assumption that about being left alone but instead requirement to quote the time that will be used for billing. You can't pad that, it will be 20 days of work that client should pay for but that 20 days may be spread over next 3 months. Problem is that neither management or client hears that part even when they are repeatedly told multiple times.
I'm always explicit when asked for an estimate. It's not the most political or business savvy answer, but I say things like "this will take 2 hours. On average I'll have two hours of focused time per day, so 10 days."
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.
> 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.
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
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.
So the rule is actually "yes, and..". The "and" is actually the crucial bit because if you just say "yes" without adding information the scene stalls (you always want to be filling in more and more details). "No, but.." tends to be frowned on because it reboots the scene and invalidates your partners scene painting... but in a corporate context I think "no, but instead.." might be the better answer (if you have an "instead", of course). Then youre still addressing the concern by adding new info, but youre not committing prematurely
Its in the same spirit because you're not invalidating the problem or concern that created the request, but youre adding new information and context that way. I like your attitude but I think saying Yes to everything can be harmful if you have info they dont have that might factor into decisions. I think no, but with an alternative, can be really productive.
My first real programming job I had was working for a guy who hired lots of contractors. And he was frequently angry with the programmer that loved to say "no I can't do that" only to have the same programmer come back a week later with a possible solution.
Since this experience I almost always answer "yes" to all client requests but with a list of compromises required to get something built. It keeps everyone involved happy, even me.
This approach is covered extensively in the book 'Getting to Yes And: The Art Of Business Improv' by Bob Kulhan, which is one of the few books I would consider a must read for anyone interested in technical leadership.
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.
One thing I try to do is to never say something is impossible or to refuse to do as instructed outright. Of course everything is possible, it's just a matter of how much effort is reasonable to put in.
If my boss comes up to me with "can we do unreasonable thing X" it's not my job to change his mind. It's my job to provide him all the relevant data and then let him decide on the course. If the request would take a large amount of effort I let him know. If the request would cause bugs or problems elsewhere I let him know. If the request would (in my opinion) upset users I let him know. What I don't do is tell him no.
If when given all the pertinent information my boss still decides it's a good idea to spend a month straight implementing a bug then I'm happy to oblige but only after all the information is on the table.
He's captain Picard and I'm chief engineer La Forge. The captain decides, and the crew executes.
Of course there's a couple catches to this approach where it doesn't work. If my boss would ask me to do something unethical I'd first try to tell him why it's a bad idea, before firmly refusing. I do this knowing full well that this might injure our working relationship.
The other assumption this method makes is that your boss is actually good at his job. A boss that makes unilateral decisions without consulting the experts that work under him is bad at his job. A boss that takes it personally when you tell him his ideas aren't good is bad at his job. A boss that isn't open to discussing approaches is bad at his job. A boss that tries to dictate how exactly you do your job is bad at his job.
Now of course all the above doesn't mean I'm acting weak-willed or indecisive. If I disagree with a course of action I let it be known. I'm not hiding my opinion. But I do respect that my job is to implement business demands and my boss' job is to gather, distill, and communicate business demands.
Anyways that's my approach and it has served me well so far.
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.
yeah, the converse of what the article talks about is that software engineers tend to be pretty arrogant and dismiss suggestions and requests from users and designers, and just treating them like people and seriously trying to find common ground gets you very far.
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.
If anything the article really undersells it by calling the meetings "useless". I'm a programmer, but most of my experience over the past 12 years has been client-facing, and these things often go beyond simply wasting time to actively harming your project. Much like the idle engineers who they invent work for in the article, idle meeting minutes get filled with planning that completely ignores actual business needs.
You make a meeting 20 minutes, everyone shares their progress and can plan their week. You make that meeting an hour, and 20 more minutes are spent investigating someone's "concern" over an imaginary problem, and the next 20 finding solutions to this imaginary problem. Because that's the end of the meeting, mentally this becomes everyone's priority afterwards, and the day that would've been spent continuing on a healthy project is now wasted solving something that doesn't need a solution.
> 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
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.
> 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. :)
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.
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.
I work in a product role at a mid-size enterprise. I'm happy to involve anyone and everybody in high-level product discussions. But in order to do that you actually need some kind of insight into the business you're actually working for.
How will the customers buy the product? Is this kind of signup suitable for our demographic? How will component Y delivered by ASP vendor X in the value chain be impacted if we do Z? How much money will we (roughly) make for each customer? What will be the total profit potential given N percent of our target customers sign up? Is this initiative significant or insignificant for our business? Is it regulatory compliance or a major new business?
The developer response is (unfortunately) very often a major discussion along the lines of "this should be a lambda function", "no, this should run in our k8 cluster" or "we should migrate the app we just built last year to some fancy new technology I just read about on Hacker News, then we can build this in no time".
Sorry, but that's acting like a craftsman. Acting like a craftsman gets you treated like a craftsman. Management (or I) don't care about serverless or Azure or AWS. And when you don't understand basic business priorities I won't trust the "agile developer" using a three hours fixing a pixel alignment issue on a non-standard Android Phone on the least visited "compliance only" webpage.
I vividly remind a session where one of our SVPs talked about the main business problems and plans for almost one hour in an all-department meeting. One front-end developer raised his hand and excused the slow rate of change of change at a certain (and important) application with "it was built with jquery and no one has touched it since 2014".
The exceptions are (we are not Google) rare and very valuable - which is why they often are promoted. In my experience business intelligence, backend developers and database people are most "business aligned" or "business focused". Front-end developers at the other end.
I deliberately became the just a job guy. Why should I bother my arse coming up with “insights into the product” - a product which I don’t own, in a company which I don’t own? They’re still only gonna pay me as a developer. I might as well run my own business if I have to deal with all that. Now I’ll be a short-order cook for 8 hours and forget about work once I’ve left it... at least it’s relaxing.
> 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.
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.
> 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?
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.
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.
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.
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.
> 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.
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.
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. :)
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.
> 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.
[+] [-] ledauphin|6 years ago|reply
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.
[+] [-] drewbug01|6 years ago|reply
Bugs are written by all seniority levels of engineers. “To err is human,” after all. Junior developers hold no monopoly on mistakes.
[+] [-] drewcoo|6 years ago|reply
Both of those work better than ignoring overhead or refusal to estimate, imho.
[+] [-] pfranz|6 years ago|reply
[+] [-] losteric|6 years ago|reply
My team's process is to estimate and track dev non-dev time with our other sprint metrics at dev-day granularity. ie last sprint I estimated 2 non-dev days for product / design discussions, factoring in the meetings/doc writing/cost of mental randomization/etc. Planning and retrospective provide opportunities to reflect on reducing communication overhead within the team, and the metric is valuable for pushing back on top-down management-mandated overhead.
[+] [-] PretzelFisch|6 years ago|reply
[+] [-] amelius|6 years ago|reply
[+] [-] dmz73|6 years ago|reply
[+] [-] _raoulcousins|6 years ago|reply
[+] [-] UglyToad|6 years ago|reply
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.
[+] [-] jlarocco|6 years ago|reply
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.
[+] [-] lobster45|6 years ago|reply
[+] [-] sz4kerto|6 years ago|reply
Agile development doesn't work without context anyway.
[+] [-] stephenboyd|6 years ago|reply
[+] [-] itronitron|6 years ago|reply
Worth noting that as I stopped saying no I also stopped feeling treated like an assembly line worker.
[+] [-] overgard|6 years ago|reply
Its in the same spirit because you're not invalidating the problem or concern that created the request, but youre adding new information and context that way. I like your attitude but I think saying Yes to everything can be harmful if you have info they dont have that might factor into decisions. I think no, but with an alternative, can be really productive.
[+] [-] RobertRoberts|6 years ago|reply
Since this experience I almost always answer "yes" to all client requests but with a list of compromises required to get something built. It keeps everyone involved happy, even me.
[+] [-] Z1515M8147|6 years ago|reply
[+] [-] blablabla123|6 years ago|reply
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.
[+] [-] Doxin|6 years ago|reply
If my boss comes up to me with "can we do unreasonable thing X" it's not my job to change his mind. It's my job to provide him all the relevant data and then let him decide on the course. If the request would take a large amount of effort I let him know. If the request would cause bugs or problems elsewhere I let him know. If the request would (in my opinion) upset users I let him know. What I don't do is tell him no.
If when given all the pertinent information my boss still decides it's a good idea to spend a month straight implementing a bug then I'm happy to oblige but only after all the information is on the table.
He's captain Picard and I'm chief engineer La Forge. The captain decides, and the crew executes.
Of course there's a couple catches to this approach where it doesn't work. If my boss would ask me to do something unethical I'd first try to tell him why it's a bad idea, before firmly refusing. I do this knowing full well that this might injure our working relationship.
The other assumption this method makes is that your boss is actually good at his job. A boss that makes unilateral decisions without consulting the experts that work under him is bad at his job. A boss that takes it personally when you tell him his ideas aren't good is bad at his job. A boss that isn't open to discussing approaches is bad at his job. A boss that tries to dictate how exactly you do your job is bad at his job.
Now of course all the above doesn't mean I'm acting weak-willed or indecisive. If I disagree with a course of action I let it be known. I'm not hiding my opinion. But I do respect that my job is to implement business demands and my boss' job is to gather, distill, and communicate business demands.
Anyways that's my approach and it has served me well so far.
[+] [-] fenwick67|6 years ago|reply
[+] [-] mooreds|6 years ago|reply
https://letterstoanewdeveloper.com/2019/09/02/the-art-to-and...
[+] [-] throwawayimp|6 years ago|reply
[+] [-] 0x262d|6 years ago|reply
[+] [-] unnouinceput|6 years ago|reply
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.
[+] [-] jkoudys|6 years ago|reply
You make a meeting 20 minutes, everyone shares their progress and can plan their week. You make that meeting an hour, and 20 more minutes are spent investigating someone's "concern" over an imaginary problem, and the next 20 finding solutions to this imaginary problem. Because that's the end of the meeting, mentally this becomes everyone's priority afterwards, and the day that would've been spent continuing on a healthy project is now wasted solving something that doesn't need a solution.
[+] [-] growlist|6 years ago|reply
...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
[+] [-] bonoboTP|6 years ago|reply
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.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] amenod|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] Aeolun|6 years ago|reply
[+] [-] mattwad|6 years ago|reply
[+] [-] EthicalHacker03|6 years ago|reply
I work in a product role at a mid-size enterprise. I'm happy to involve anyone and everybody in high-level product discussions. But in order to do that you actually need some kind of insight into the business you're actually working for.
How will the customers buy the product? Is this kind of signup suitable for our demographic? How will component Y delivered by ASP vendor X in the value chain be impacted if we do Z? How much money will we (roughly) make for each customer? What will be the total profit potential given N percent of our target customers sign up? Is this initiative significant or insignificant for our business? Is it regulatory compliance or a major new business?
The developer response is (unfortunately) very often a major discussion along the lines of "this should be a lambda function", "no, this should run in our k8 cluster" or "we should migrate the app we just built last year to some fancy new technology I just read about on Hacker News, then we can build this in no time".
Sorry, but that's acting like a craftsman. Acting like a craftsman gets you treated like a craftsman. Management (or I) don't care about serverless or Azure or AWS. And when you don't understand basic business priorities I won't trust the "agile developer" using a three hours fixing a pixel alignment issue on a non-standard Android Phone on the least visited "compliance only" webpage.
I vividly remind a session where one of our SVPs talked about the main business problems and plans for almost one hour in an all-department meeting. One front-end developer raised his hand and excused the slow rate of change of change at a certain (and important) application with "it was built with jquery and no one has touched it since 2014".
The exceptions are (we are not Google) rare and very valuable - which is why they often are promoted. In my experience business intelligence, backend developers and database people are most "business aligned" or "business focused". Front-end developers at the other end.
[+] [-] silveroriole|6 years ago|reply
[+] [-] awinter-py|6 years ago|reply
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.
[+] [-] d23|6 years ago|reply
Citation needed.
[+] [-] progman32|6 years ago|reply
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-...
[+] [-] pedrorijo91|6 years ago|reply
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?
[+] [-] ncmncm|6 years ago|reply
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.
[+] [-] solidasparagus|6 years ago|reply
[+] [-] geewee|6 years ago|reply
[+] [-] CM30|6 years ago|reply
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.
[+] [-] thayne|6 years ago|reply
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.
[+] [-] alexfromapex|6 years ago|reply
[+] [-] viburnum|6 years ago|reply
[+] [-] winrid|6 years ago|reply
[+] [-] sysbin|6 years ago|reply
[+] [-] tracer4201|6 years ago|reply
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.
[+] [-] NikolaeVarius|6 years ago|reply