Evil programmer's tip: avoid “easy” things (2016)(yosefk.com)
yosefk.com
Evil programmer's tip: avoid “easy” things (2016)
http://yosefk.com/blog/evil-tip-avoid-easy-things.html
202 comments
It's sort of like how it's better to be a firefighter than a maintainer, which is guess is the point. The ease may be similar, but coming in to save everyone from an explosion gets you more points than oiling the valve every day so pressure doesn't build up in the first place. It's a cultural issue that is very hard to combat.
God, this hurts. I pride myself in avoiding deadlines by looking to the future and getting things done before they're needed, so when the time comes, I can focus on polish and integration. But then some dick in management notices that I did this thing in a day, doesn't count the prep-work, and hands me an impossible deadline that's already promised to a customer...
Reminds me of moments I had early in my career where I was the hero for fixing problems I caused. :) That company didn't have code reviews and my bosses weren't very technical, so it was pretty easy to pretend like I wasn't at fault for anything. Sometimes they'd figure out that I caused the problems and even then it didn't seem to really matter. If I had the skills I have now 7 years later, my bosses would probably think they're overpaying me because it wouldn't seem to them like I'm doing anything more of the time.
If you don't get enough praise for not breaking things, get a days since a workplace accident sign, and update it every day.
Set it to zero when you break something.
Edit to add: you should be able to get some praise (or at least self-praise) at milestones like 30/60/90/180/365 days without an incident.
Set it to zero when you break something.
Edit to add: you should be able to get some praise (or at least self-praise) at milestones like 30/60/90/180/365 days without an incident.
Recently one of my clients noticed something we had broken on their website. When they noticed it, we fixed it in a matter of minutes. They were so pumped on the response time they then left us a very glowing public review.
I remember John Sterman doing some system dynamics modelling on Oil Refinery maintenance vs actual fire fighting[1].
The results are just as you suggest.
Personally speaking I'd like to work at the software equivalent of Toyota. Where the whole organisation is constantly looking for feedback about development processes and how barriers to quality can be removed.
I think the problem is that how to get credit for the not having problems in the first place.
1. http://web.mit.edu/jsterman/www/SDG/maint.pdf
The results are just as you suggest.
Personally speaking I'd like to work at the software equivalent of Toyota. Where the whole organisation is constantly looking for feedback about development processes and how barriers to quality can be removed.
I think the problem is that how to get credit for the not having problems in the first place.
1. http://web.mit.edu/jsterman/www/SDG/maint.pdf
Indeed, thank your (figurative and literal) janitors and maintenance staff! :)
it's better to be a firefighter than a maintainer
Oh this is very true. I've achieved a pretty good reputation in my org getting called in when things have gone wrong somewhere. Not so much for typical day-to-day work.
Oh this is very true. I've achieved a pretty good reputation in my org getting called in when things have gone wrong somewhere. Not so much for typical day-to-day work.
Perhaps you can staff your firefighting crew with the effective maintainers. They've been oiling their valves, so they have time to spare helping fight the fire. This becomes doubly visible.
Probably has to do with our brains preferring instant gratification over long term payoffs.
Indeed. Sometimes the saviour is the one responsible for the disaster but companies also need their heroes or at least that's how I interpret certain management decisions. Been on both sides of the fence.
true, the problem is when the same person is both the arsonist and the fire fighter. It becomes a habit for some people to show "heroic" effort. No effort is done to see who caused the issue, the spotlight is usually on who fixed it.
These "arsonists" also have higher velocity in delivering features since they don't care about quality, so they get into the good books of upper management.
When trouble is solved before it forms, who calls that clever? When there is victory without battle, who talks about bravery?
- Sun Tzu
- Sun Tzu
"but coming in to save everyone from an explosion gets you more points than oiling the valve every day so pressure doesn't build up in the first place. It's a cultural issue that is very hard to combat."
The "hero" part of the firefighter comes from the fact, that they actually go towards real danger as part of their job, they often do unpaid and voluntarily. (A big fire out of control, is a very scary thing)
While the maintainance worker is usually not in danger, if he does his job right.
" It's a cultural issue that is very hard to combat."
So I do not really see a issue here to combat (when using this metaphor). The actual firefighters deserve their praise.
And if some companies are too shortsighted and praise the people heroically fixing their own mess, then I would use a different metaphor there, to adress this.
The "hero" part of the firefighter comes from the fact, that they actually go towards real danger as part of their job, they often do unpaid and voluntarily. (A big fire out of control, is a very scary thing)
While the maintainance worker is usually not in danger, if he does his job right.
" It's a cultural issue that is very hard to combat."
So I do not really see a issue here to combat (when using this metaphor). The actual firefighters deserve their praise.
And if some companies are too shortsighted and praise the people heroically fixing their own mess, then I would use a different metaphor there, to adress this.
What metaphor would you use though?
Clearly there are companies praising heroic fixes, while not praising too much regular maintenance.
Clearly there are companies praising heroic fixes, while not praising too much regular maintenance.
I guess firefighting is the right metaphor, to fixing big errors in live production environments: it takes a different skill and mindset, to do things under pressure, nothing wrong to praise that.
But I think it is wrong, to talk down the job of actual firefighters, because:
"Clearly there are companies praising heroic fixes, while not praising too much regular maintenance"
that is a seperate issue.
But I think it is wrong, to talk down the job of actual firefighters, because:
"Clearly there are companies praising heroic fixes, while not praising too much regular maintenance"
that is a seperate issue.
the fire metaphor still works: we have arsonists (that build up tech debt or just bad practices) that turn firefighters (by fixing in emergency mode).
Of course not all tech debt is bad, the trick is know when to use it to good effect, not building it up everywhere only to pay it back at the costliest moment. It's all a balancing act.
Of course not all tech debt is bad, the trick is know when to use it to good effect, not building it up everywhere only to pay it back at the costliest moment. It's all a balancing act.
Thanks for connecting these dots! You've put words to a situation I've experienced before but never fully grokked
I will say as someone who has to wrangle a lot of junior devs -- don't have imposter syndrome on this. The hard part is sticking with the issue and seeing it through to the logical conclusion. Many people have difficulty even conceptualizing the steps that need to be taken in order to solve a problem. If you are smart enough to get help from someone in devops and understand the advice they gave, you're doing the same stuff senior devs and CTOs do on a daily basis. We're all frauds lol
I'm a senior dev I say this only because I have to.
The problem with encouraging developers to speak up when they're stuck is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard. In some sense senior developers have a real leg up here because they know that they're capable of building systems for large companies.
I've seen many junior developers fired because "they require too much hand holding" and I don't think the advice should be "speak up" but rather "make at least one friend as soon as you possibly can that you can privately ask questions to so you don't look like an idiot" and I know this advice is better for the individual than the company, but it's the reality. The selection function for new, junior employees is "can they get the things done with minimal hand holding" not "do they ask questions" and I'm not ok with that, but it is the reality and we shouldn't push juniors into situations that would get them fired before they're up to speed.
The problem with encouraging developers to speak up when they're stuck is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard. In some sense senior developers have a real leg up here because they know that they're capable of building systems for large companies.
I've seen many junior developers fired because "they require too much hand holding" and I don't think the advice should be "speak up" but rather "make at least one friend as soon as you possibly can that you can privately ask questions to so you don't look like an idiot" and I know this advice is better for the individual than the company, but it's the reality. The selection function for new, junior employees is "can they get the things done with minimal hand holding" not "do they ask questions" and I'm not ok with that, but it is the reality and we shouldn't push juniors into situations that would get them fired before they're up to speed.
I really don't think I agree with this. The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first.
Whatever the work is, the important thing is that it gets done, usually as efficiently and as good as possible. If it takes me explaining the same thing 3 times in a row to get something done properly the first time I'd rather do that than have to go back and fix things later.
And honestly, everybody starts somewhere, the best way to learn is by asking questions. If someone is asking me questions, it tells me they recognize they don't know everything, care enough to learn and are humble enough to ask for help.
Such qualities are rare in people and i've found every time, the people like that make the best employees and coworkers.
Whatever the work is, the important thing is that it gets done, usually as efficiently and as good as possible. If it takes me explaining the same thing 3 times in a row to get something done properly the first time I'd rather do that than have to go back and fix things later.
And honestly, everybody starts somewhere, the best way to learn is by asking questions. If someone is asking me questions, it tells me they recognize they don't know everything, care enough to learn and are humble enough to ask for help.
Such qualities are rare in people and i've found every time, the people like that make the best employees and coworkers.
> The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first.
Until you get the person who questions everything, draining all your time. Then they become reliant on you, and stop thinking for themselves.
Until you get the person who questions everything, draining all your time. Then they become reliant on you, and stop thinking for themselves.
This can usually be solved by coaching, not only for this person, but for the teammates who are spending more time answering questions.
For coaching the questioner, I ask them how they approach finding information, and recommend they time box their exploration, and only ask their question if they've given it a good try. I I also will describe my personal workflow to find answers when answering their questions.
For coaching the rest of the team, I often suggest they ask "what have you tried so far?" or "where have you looked so far?" before just giving an answer. This can help show knowledge gaps, and oftentimes the questioner will take another look and discover the answer themselves.
And yes, if they never get away from this behavior even after getting feedback multiple times, then that turns into a different sort of conversation.
For coaching the questioner, I ask them how they approach finding information, and recommend they time box their exploration, and only ask their question if they've given it a good try. I I also will describe my personal workflow to find answers when answering their questions.
For coaching the rest of the team, I often suggest they ask "what have you tried so far?" or "where have you looked so far?" before just giving an answer. This can help show knowledge gaps, and oftentimes the questioner will take another look and discover the answer themselves.
And yes, if they never get away from this behavior even after getting feedback multiple times, then that turns into a different sort of conversation.
I guess maybe I could clarify. I do agree there's a difference between a person who asks a lot of questions and one who just asks questions out of laziness. There's a difference. If a person is asking a lot of questions, especially the same ones over and over without any clear signs of gaining understanding, yeah there's definitely a problem, that person is dragging down work then.
But I do think there's a difference. If a person generally asks a lot of questions, but there's clear signs of improvement and they're trying to pull their weight, then I really don't see it as a bad thing.
But I do think there's a difference. If a person generally asks a lot of questions, but there's clear signs of improvement and they're trying to pull their weight, then I really don't see it as a bad thing.
I agree both as a junior and as a senior human.
[deleted]
That is what I believe you believe and I understand where it is coming from. I've managed juniors and I know they make mistakes.
That said, if a junior brings up a question like "why does this error for some tests, but not others?"
That said, if a junior brings up a question like "why does this error for some tests, but not others?"
records = some_orm_thing()
some_model_ids, other_ids = map(list, zip(*records))
[deleted]
My wording was maybe a little strong, I did try and clarify a bit in another comment below but, I was maybe a little bit unclear and think I might not have fully understood the point you were making. I admit, I did take it as juniors should just shut up, which i admit probably wasn't the most good faith way to interpret it.
I agree there's a difference between the kind of question like the one above vs. something like 'Why isn't there a check in there before unpacking a record?'
The first question is basically 'Teach me stuff I should know' the second is more along the lines of 'Why do we do it this way?'
And there does come a limit, if after a month they're still asking the same questions, not really seeming to have learned anything, it's probably not going to change.
I dunno, really I guess it usually comes down to the person and I hate to say it but, how annoying I find the questions and the person's behaviour.
I agree there's a difference between the kind of question like the one above vs. something like 'Why isn't there a check in there before unpacking a record?'
The first question is basically 'Teach me stuff I should know' the second is more along the lines of 'Why do we do it this way?'
And there does come a limit, if after a month they're still asking the same questions, not really seeming to have learned anything, it's probably not going to change.
I dunno, really I guess it usually comes down to the person and I hate to say it but, how annoying I find the questions and the person's behaviour.
I'm really happy you responded because I fully agree with you.
I think my larger point was that smart juniors should seek to get clarification privately after exhausting their own skill, but you're absolutely right that they should raise issues as they come up in a thoughtful way to accelerate the team and their own growth.
I think my larger point was that smart juniors should seek to get clarification privately after exhausting their own skill, but you're absolutely right that they should raise issues as they come up in a thoughtful way to accelerate the team and their own growth.
I agree. Whatever level a developer is, there is a mountain of tedious work to be done. Asking is more like getting directions, not taking a free ride. Good developers grow in a method negotiation skill, not in a complete autonomy, because exact methods and their details may and will be very important for future integrations. In a complete isolation, no plural number of seniors will create a good system. It’s strange to expect that from noobs.
Of course there is always a level of knowledge too low to participate constructively, but that’s another scope (fire your HR along with yet another zero-skills guy, etc).
Of course there is always a level of knowledge too low to participate constructively, but that’s another scope (fire your HR along with yet another zero-skills guy, etc).
I am in a senior(ish) position and honestly I prefer talking things out with at least one other person before making larger decisions. Even if they're a "junior" person, explaining my ideas to someone helps me see the spots where I don't really understand the problem before I get to solving it. I especially like it when people disagree with me because it forces me to construct a real argument in support of my approach.
> is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard
It's also important to know if it is a bug or incomplete implementation of a feature. Sometimes the code is over engineered or there are no docs to help understand its intent.
If junior devs get fired for asking questions, or because that makes them look like idiots, I'd take a hard look at whether they have the support needed to set them up for success. Maybe the solution is actually "don't hire Jr devs" because the organization isn't able to support them.
It's also important to know if it is a bug or incomplete implementation of a feature. Sometimes the code is over engineered or there are no docs to help understand its intent.
If junior devs get fired for asking questions, or because that makes them look like idiots, I'd take a hard look at whether they have the support needed to set them up for success. Maybe the solution is actually "don't hire Jr devs" because the organization isn't able to support them.
I think speaking up is fine. It is when ANY engineer is lazy and doesn't bother to:
a) do any research before asking the question,
b) trying to understand the answer given or
c) doesn't follow the answer given.
> The problem with encouraging developers to speak up when they're stuck
I'm not actually encouraging that. I'm encouraging them to not have imposter syndrome when they actually manage to fix something, regardless of their methods. The ones who ask stupid questions, in my experience, don't end up fixing the issue ever because they don't understand what they're doing enough to ask the right questions, so they wouldn't be at this point.
I'm not actually encouraging that. I'm encouraging them to not have imposter syndrome when they actually manage to fix something, regardless of their methods. The ones who ask stupid questions, in my experience, don't end up fixing the issue ever because they don't understand what they're doing enough to ask the right questions, so they wouldn't be at this point.
It varies widely by company culture. At a previous job we had a Slack channel called #dumb-questions, specifically for exactly this type of thing; a no-judgement zone where everyone could share the job of filling in each other's mental gaps (one problem with finding just a single friend to ask questions of is that you start to worry about bothering them too much; this way no one person was a choke point)
I've never worked at a place that treats juniors like that, so my experience is opposite of yours. It's totally fine for the more senior dev to push back and say, "I think you kind figure this one out, maybe look into X", but juniors should be asking questions, it's one of the primary ways to become un-junior.
I've never even heard of a junior fired for "asking too many questions".
I've never even heard of a junior fired for "asking too many questions".
IMHO the rule of thumb is - no stupid questions, if repeated refer to previous answer, if repeated consider firing an idiot, if it came from above you - consider promotion or giving a notice.
My intuitive response as I started to read this was a sort of "gentle-art" thought: Would it be helpful for someone to start their question: "I don't know if I should know this [already]..." ?
If the answer is [in context] indeed "yes", then that could help tune their threshold for when learn-by-self vs learn-by-others will be appropriate [again, in that context].
If the answer is [in context] indeed "yes", then that could help tune their threshold for when learn-by-self vs learn-by-others will be appropriate [again, in that context].
> developers fired because "they require too much hand holding" and I don't think the advice should be "speak up" but rather "make at least one friend as soon as you possibly can that you can privately ask questions to so you don't look like an idiot" and I know this advice is better for the individual than the company, but it's the reality. The selection function for new, junior employees is "can they get the things done with minimal hand holding" not "do they ask questions" and I'm not ok with that, but it is the reality and we shouldn't push juniors into situations that would get them fired before they're up to speed.
Thank you for saying this. I haven’t heard it being said anywhere else, but knowing people that you can DM and ask about things first is “socially” a better strategy than an ask tons of questions in a public thread. What’s also worked for me is to have a private channel meant only for developers (no manager, PM etc. Just devs, free to ask any question without judgement).
People instinctively assume the junior person asking questions is less competent.
Thank you for saying this. I haven’t heard it being said anywhere else, but knowing people that you can DM and ask about things first is “socially” a better strategy than an ask tons of questions in a public thread. What’s also worked for me is to have a private channel meant only for developers (no manager, PM etc. Just devs, free to ask any question without judgement).
People instinctively assume the junior person asking questions is less competent.
That's pretty much it. There's a certain category of people with a certain attitude towards debugging. You have to be able to break it down into steps - sometimes from "first principles". Then work up and identify where the issue is and how to resolve it. Sometimes it requires looking at logs and simulating production conditions and other times you may have to understand low level network stack.
I still remember the time trying to reproduce and fix a certain issue. We had a 3-node cluster mysql database setup with one main and two replicas. The replicas are read-only. If one replica goes down, reads shouldn't be affected at all. We had an application layer on top of this to coordinate and enforce these requirements. Every which way you look at the code, there's no reason why this shouldn't work. And yet, when one node went down in production under a very particular circumstance with the network, it took down the entire cluster - not that the cluster was not reachable - it wouldn't allow reads and just hang.
Tracing it took me down the hole of understanding the precise network issue (fading memory - I think the machine wasn't responding back and tcp kept retrying) + linux tcp setting (I think tcp_delack_min) + a java networking setting + how thread safety was setup in the application (do not use synchronized at the method level). It took a week to diagnose.
Recently, there was a minor issue with adapting a sample Spark UDF to work with our setup and it took the developers 3 weeks and they kept giving up after every try.
I still remember the time trying to reproduce and fix a certain issue. We had a 3-node cluster mysql database setup with one main and two replicas. The replicas are read-only. If one replica goes down, reads shouldn't be affected at all. We had an application layer on top of this to coordinate and enforce these requirements. Every which way you look at the code, there's no reason why this shouldn't work. And yet, when one node went down in production under a very particular circumstance with the network, it took down the entire cluster - not that the cluster was not reachable - it wouldn't allow reads and just hang.
Tracing it took me down the hole of understanding the precise network issue (fading memory - I think the machine wasn't responding back and tcp kept retrying) + linux tcp setting (I think tcp_delack_min) + a java networking setting + how thread safety was setup in the application (do not use synchronized at the method level). It took a week to diagnose.
Recently, there was a minor issue with adapting a sample Spark UDF to work with our setup and it took the developers 3 weeks and they kept giving up after every try.
People in the category you describe are few and far apart in my experience.
To me solving a problem like the one you describe here is one of the biggest joys of working with IT.
Though it seems to come at the expense of being able to design large systems. Not sure if there is a way to be good at both.
To me solving a problem like the one you describe here is one of the biggest joys of working with IT.
Though it seems to come at the expense of being able to design large systems. Not sure if there is a way to be good at both.
How does skill at deep-diving into complex unknown technical problems hurt the ability to design large systems?
[deleted]
I’d guess that taking the time to deep-dive a problem takes away from time to design large systems.
computing is a fraud, a CPU is literally a rock that we tricked into thinking
You’re oversimplifying.
We didn’t just trick a rock into thinking - we beat on it until it was really thin, shoved a little bit of lightning inside of it, then tricked it into thinking.
We didn’t just trick a rock into thinking - we beat on it until it was really thin, shoved a little bit of lightning inside of it, then tricked it into thinking.
If a CPU is thinking, then all rocks are constantly thinking their rocky thoughts, contemplating the immeasurable eons of their existence. A CPU is, then, merely a rock which we have made to think some thoughts which are to our benefit.
This gave me a great belly laugh
> It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.
I think that's why he's putting scare quotes around "easy", because it's referring to what managers or stakeholders think rather than the real level of challenge.
I think that's why he's putting scare quotes around "easy", because it's referring to what managers or stakeholders think rather than the real level of challenge.
He explicitly says this in the article. I think the majority of commenters only read the title.
> I think the majority of commenters only read the title.
I've lost count of how many times this has happened.
In one case, I went through and read several dozen comments on an article. No exaggeration: all commenters (100%) said nothing whatsoever about the article's text. They were all just holding forth on their own opinions and experiences related to the headline.
I've lost count of how many times this has happened.
In one case, I went through and read several dozen comments on an article. No exaggeration: all commenters (100%) said nothing whatsoever about the article's text. They were all just holding forth on their own opinions and experiences related to the headline.
I've gotta ask : How do you read these quickly ? It'd take me so much time to read even half of the articles from threads I'm somewhat interested in, I can't help but feel that trying to get the gist of it by reading the comments is the most efficient way for me. Well, it would've been, if the people commenting actually read the article.
Maybe if the article was right here instead of a click away, more people would read it.
I don't think so.
Just look at YouTube, lots of people comment on videos without actually watching the video despite it being right there.
Just look at YouTube, lots of people comment on videos without actually watching the video despite it being right there.
I read the article, doesn’t mean I can’t leave an anecdote and reiterate the same point.
> if management/product view something as easy or hard.
This applies not just to work done, but work to be done.
Once the business people asked me to do something that turned out to be extraordinarily difficult. Afterwards we were talking about it and they mentioned that they considered asking me to do it a different way that would have achieved the same goal, but they thought the second option would be harder, so they only asked me to do the first option. The second option turned out to be extremely easy and I could have finished it in 5% of the time option 1 took.
This applies outside of programming as well. One time I was building kitchen cabinets for a remodel. I gave my wife 2 options for the doors. She went with the more difficult option. After they were done she admitted that she preferred the other option, but thought it would be harder so she went with the less desirable option to save me work. Facepalm.
This applies not just to work done, but work to be done.
Once the business people asked me to do something that turned out to be extraordinarily difficult. Afterwards we were talking about it and they mentioned that they considered asking me to do it a different way that would have achieved the same goal, but they thought the second option would be harder, so they only asked me to do the first option. The second option turned out to be extremely easy and I could have finished it in 5% of the time option 1 took.
This applies outside of programming as well. One time I was building kitchen cabinets for a remodel. I gave my wife 2 options for the doors. She went with the more difficult option. After they were done she admitted that she preferred the other option, but thought it would be harder so she went with the less desirable option to save me work. Facepalm.
I think this is a perfect example of why it is necessary to effectively communicate the relative tradeoffs and costs of option A and B when someone asks you to do something.
And to also also questions to dig into what they are really trying to accomplish, and why they are trying to do it that way.
And to also also questions to dig into what they are really trying to accomplish, and why they are trying to do it that way.
this is what the article talks about, you want to work on things you know are easy, but others think is hard
In the last 5 years I have probably written 100k+ lines of production code. My most celebrated feature was about 100 lines to store a single flag in a per user store.
Way to describe the engineer/business disconnect.
You are proud of the complex problems which you have solved over the years. The business is proud of the little widget that made everyone's jobs a bit easier.
I've seen people take this lesson to heart and go full Wally.
You are proud of the complex problems which you have solved over the years. The business is proud of the little widget that made everyone's jobs a bit easier.
I've seen people take this lesson to heart and go full Wally.
It was a little widget, just needed a bit of state persisted across sessions. The pain point was at page load, so about as far as most business pays attention. Also I do feel like it caused me to go full Wally without realizing it.
>I've seen people take this lesson to heart and go full Wally.
Who is Wally?
Who is Wally?
but if management/product view something as easy or hard
Yep. My job involves a fair amount of coding but it's geared toward data analysis. I might create something in a day with dozens of data points and look like a hero, while another project might take a week and the output is a single number.
Actually, yesterday it was two numbers, X & Y. (Upper & lower bounds on something). Deceptively simple in appearance to anyone consuming the information, but behind the scenes it took an order of magnitude more time to make it a dynamic model based on latest available data instead of a static hand-crafted analysis.
Yep. My job involves a fair amount of coding but it's geared toward data analysis. I might create something in a day with dozens of data points and look like a hero, while another project might take a week and the output is a single number.
Actually, yesterday it was two numbers, X & Y. (Upper & lower bounds on something). Deceptively simple in appearance to anyone consuming the information, but behind the scenes it took an order of magnitude more time to make it a dynamic model based on latest available data instead of a static hand-crafted analysis.
> It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.
That's eye opening, thank you! I've once worked on a "hard" statistical model and all I got from my boss' boss was a "who cares" face. Then he was so happy to see our (to my view) dumb web app, he didn't even realized it was the model behind that app that consumed 80% of my time/energy :/
That's eye opening, thank you! I've once worked on a "hard" statistical model and all I got from my boss' boss was a "who cares" face. Then he was so happy to see our (to my view) dumb web app, he didn't even realized it was the model behind that app that consumed 80% of my time/energy :/
I've had this plenty of times, where praise and accoaldes come down tot he person who made the prettiest or shiniest thing. It's kind of why I moved into frontend development, I always have something so show every week, and management are always happy, since I always look like I have made amazing progress. It's gaming the system, but I would rather this, than what you experienced, where the developer looks like they are wasting time in the eyes of management.
Those two problems sound like they could differ substantially in perceived business value. Maybe it’s not how hard management think it is, but how valuable?
If management thinks it’s easy and it has big business value - they’re going to understaff it and expect it done tomorrow. Which is gonna hurt someone, and it usually isn’t the execs.
I feel your pain and I have been/am in your shoes.
Unfortunately, you will not get the kudos for things you build unless you spend time selling those projects. I personally hate this as I want to spend my energy on building things that make a difference.
Unfortunately, you will not get the kudos for things you build unless you spend time selling those projects. I personally hate this as I want to spend my energy on building things that make a difference.
Ouch. This hits close to home.
I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems)
It's because I'm seen as a technician, not an engineer or a scientist.
That's because I'm the person everyone picks for the "hey, just whip up this quick demo / generate this report / prototype this idea for me", and therefore I get critiqued when it's not fast enough / polished enough, despite it being a "drop everything and have this done by 10pm" situation every time.
The big things I've accomplished, other people have _always_ gotten credit for. The things that fail, I get the blame for.
So serious advice from someone who's too old to change it now: SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Once you start, it's a trap that's really hard to get out of and gets you nowhere career wise.
I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems)
It's because I'm seen as a technician, not an engineer or a scientist.
That's because I'm the person everyone picks for the "hey, just whip up this quick demo / generate this report / prototype this idea for me", and therefore I get critiqued when it's not fast enough / polished enough, despite it being a "drop everything and have this done by 10pm" situation every time.
The big things I've accomplished, other people have _always_ gotten credit for. The things that fail, I get the blame for.
So serious advice from someone who's too old to change it now: SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Once you start, it's a trap that's really hard to get out of and gets you nowhere career wise.
I've been the 'fixer' in so many situations and I have a tactic for this. I ask them for the following things:
- a ticket to track the work
- that they get approval from my manager to drop all of the work that I am currently doing and affect other peoples timelines
- that they document the problem and how they want it fixed
- that they get approval for the extra hours required
I've heard the term "effort asymmetry" used for this phenomenon.
If someone can spend five minutes of their own time to create a days worth of work for you, they will do that without any hesitation. If you require them to spend fifteen minutes instead, then all of a sudden these urgent requests go away.
If someone can spend five minutes of their own time to create a days worth of work for you, they will do that without any hesitation. If you require them to spend fifteen minutes instead, then all of a sudden these urgent requests go away.
Wow. I’ve understood this viscerally but it’s great to be able to describe it explicitly this way.
Having been both on the sending and receiving end of this, I’m somewhat reflexively hesitant to ask others to do things for me “on a top priority” unless there’s a really good reason (most often a production outage).
I take a somewhat gentler view in that requesters may often not be aware of the effort required by you. If you’re able to communicate that, very often that’s enough for them to reconsider their ask or it’s priority.
Of course there will be a handful of jerks who always want their requests to be prioritized.
Having been both on the sending and receiving end of this, I’m somewhat reflexively hesitant to ask others to do things for me “on a top priority” unless there’s a really good reason (most often a production outage).
I take a somewhat gentler view in that requesters may often not be aware of the effort required by you. If you’re able to communicate that, very often that’s enough for them to reconsider their ask or it’s priority.
Of course there will be a handful of jerks who always want their requests to be prioritized.
"Effort Asymmetry". That is a fantastic phrase and is so true.
Not even dumping the problem. Many managers procrastinate by delegating. "I did some work on this" - No, you didn't, you just handed the hot potato to somebody dumb enough to take it.
Notice that the problem usually doesn't get solved by this. On the contrary: These managers "work" on something and the problems multiply, not get less.
Ask everybody who wants you to do work for a spec sheet. The above mentioned people can not do this.
Again what they are really doing is to appear to be working. That is the real goal. If you force them to actually do work (spec sheet), they'll disappear or deliver a hilariously bad one.
Notice that the problem usually doesn't get solved by this. On the contrary: These managers "work" on something and the problems multiply, not get less.
Ask everybody who wants you to do work for a spec sheet. The above mentioned people can not do this.
Again what they are really doing is to appear to be working. That is the real goal. If you force them to actually do work (spec sheet), they'll disappear or deliver a hilariously bad one.
As an add-on to protecting your time. I will help just about anyone that needs help but be wary of people that send you direct slack messages.
Often they are messaging you directly because they are stuck. That is fine as we all get stuck sometimes. If they directly message you often they:
edit: the formatting is always terrible for me
Often they are messaging you directly because they are stuck. That is fine as we all get stuck sometimes. If they directly message you often they:
- are lacking the skills/time/training to do their job. Been there.
- are under pressure to get results quickly. Been there too.
- are lacking the people/resources on their team to get results. Yup, been there too.
- more horribly, they are taking credit for your knowledge and using you to get ahead. This has happened to me and I was pissed.
- In your standups/scrums/reporting, make it very well known that you 'spent X hours helping Y with Z'. You do not want to get in trouble for missing deadlines because you were helping someone else. You also want to be known as a helper/fixer because those are useful to teams.
- Move the chats from direct messages to private channels. You need to let others know what is going on and more importantly you need to spread the knowledge that you are an expert of.
- Moving to a channel also publicly sells your skills and knowledge to a wider audience.
- Moving to a channel lets all managers know that something is lacking somewhere. Either their team doesn't have enough training, people or docs to get the jobs done.
- Start writing documentation or updating the current docs. There is a gap somewhere in the docs if your knowledge is directly needed. Even 2 paragraph FAQs are useful to everyone. Having a doc will save you time in the future as you can just point people to it.
edit: the formatting is always terrible for me
I'm going to start doing this.
> SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!!
The thing is, saying no to requests from management (if it is your management of course) is going to hurt your career prospects too. Instead you should say "sure, but this thing will move the completion date of this hard and extremely important project X days, is it ok with you?" (Not having any hard and important project in the works? Fix that ASAP as the article suggests). Then ideally you reach some kind of compromise (sometimes these requests are urgent and you are the best person to handle them). If instead they say "no, I want you to do this urgent thing and complete your other projects on time, here is a nice weekend that you can use", then it is time to look for a new job.
The thing is, saying no to requests from management (if it is your management of course) is going to hurt your career prospects too. Instead you should say "sure, but this thing will move the completion date of this hard and extremely important project X days, is it ok with you?" (Not having any hard and important project in the works? Fix that ASAP as the article suggests). Then ideally you reach some kind of compromise (sometimes these requests are urgent and you are the best person to handle them). If instead they say "no, I want you to do this urgent thing and complete your other projects on time, here is a nice weekend that you can use", then it is time to look for a new job.
There needs to be a process where you can feedback too, like 1-1s and have some influence over what happens. If not, you need to switch jobs. Zero influence jobs where you are directed to so X and Y but your opinion doesn’t count really really suck!
You want to be somewhere where they make sane decisions so when management says “fix this fire” it’s genuinely serious and a rare event.
There is a holistic aspect to this - other things happening in the company, the culture, the history, the industry and even the general culture of the country / city will come into play.
You want to be somewhere where they make sane decisions so when management says “fix this fire” it’s genuinely serious and a rare event.
There is a holistic aspect to this - other things happening in the company, the culture, the history, the industry and even the general culture of the country / city will come into play.
I know it's management's job to manage and obviously they have their own agenda but...
In the past I've seen issues that I know will blow up at some point in the near-future.
Fixing thing them would also make 3 other existing low level problems go away too.
I've explained that to management but as they don't grasp an issue yet arisen they instead let me get half way through something else "important" when the issue strikes and I have to move onto fire-fighting and working through the weekend.
From the comments that doesn't seem to be uncommon. This is the sort of stuff that "agile management" is supposed to fix but because most managers (in my experience) still think in some form of waterfall.
Rule of thumb: The more senior a manager the more they think in waterfall because that's how they see their master plan unfolding.
I know there's exceptions but there aren't enough of them.
In the past I've seen issues that I know will blow up at some point in the near-future.
Fixing thing them would also make 3 other existing low level problems go away too.
I've explained that to management but as they don't grasp an issue yet arisen they instead let me get half way through something else "important" when the issue strikes and I have to move onto fire-fighting and working through the weekend.
From the comments that doesn't seem to be uncommon. This is the sort of stuff that "agile management" is supposed to fix but because most managers (in my experience) still think in some form of waterfall.
Rule of thumb: The more senior a manager the more they think in waterfall because that's how they see their master plan unfolding.
I know there's exceptions but there aren't enough of them.
When you say, "I've explained that to management" -- was this in writing?
It works much better if you do this in writing, especially if this is a public medium you can refer to, like a JIRA ticket or a message in a public channel/mailing list. This way you at least can say, "I warned you but you refused <link to refusal message>"
If you have a PhD in the field and are spending your time prepping demos and/or generating reports, then I would say: move away from where you’re currently at. Even if you think it’s too late, chances are you still can.
This can be done by either changing how you’re being perceived internally, or, the easier way: getting a different job elsewhere.
This can be done by either changing how you’re being perceived internally, or, the easier way: getting a different job elsewhere.
I'm not sure how old you are but if you're planning on working for another 5-10 years, you may as well try to make it enjoyable for yourself. Perhaps you can find a way to line things up so that your manager looks their best by giving you credit. If you can frame them in a positive light, they'll want you at the presentations making it hard for others to steal credit and giving you more exposure within the org. If you feel so negatively about your manager that you can't speak highly, maybe you're at the wrong job or on the wrong team? It's a sellers market for software engineers right now so I'd encourage you to see what the market wants to offer you. Just some thoughts - I'm sure I'm missing most of the nuance of your situation.
Years ago I realized I was the only person doing software (and original electronic hardware) in a group of 10 people; in addition the larger organization I saw was mostly mechanical engineers.
I imagined the term "programmer in a corner syndrome", to describe, among other things, the realization that one had worked for years and not one person had looked at one line of your code in all that time.
(In fairness, I primarily imagined the term, not so much felt it. I was hired in the first place because they first spent O(1million) on hardware and realized no one there could make it work.)
I imagined the term "programmer in a corner syndrome", to describe, among other things, the realization that one had worked for years and not one person had looked at one line of your code in all that time.
(In fairness, I primarily imagined the term, not so much felt it. I was hired in the first place because they first spent O(1million) on hardware and realized no one there could make it work.)
I actually like one-off requests from management. Not all requests, I try to deflect the easy/"easy" ones, explain why the hard/"easy" are hard, take the easy/"hard" ones because it would be stupid not to and actively seek the hard/"hard" ones.
To explain why "easy" problem is hard, the best way I found is to find a precedent. Like "remember that supposedly easy project that ended up costing so much money to the company, that's what you are asking me right now, I can do it, but don't expect a different result", or "No, I can't finish it by 10pm, last time it took 3 days, it will also take 3 days this time, if you want it to be done by 10pm, find someone better than me or reduce the scope". The goal, if you get the task, is to make it clear it is harder than it looks (bonus point if it isn't).
With one-off tasks, you get to learn a lot in many fields. Being a jack of all trades is interesting too. "Interesting" work can become stale if you are doing it for too long. You may think that spending all day working on a state-of-the-art project that make inspiring YouTube videos is interesting, but it can quickly become routine. But if you are recognized as a wild card, you can get to work for some time on that fancy project, maybe just because there is a library that crashes or because they need you do whip out a quick UI, but you get to see the environment, work a bit, and see if it is as interesting as it looks, and if it is, and if you really saved their ass, you have your chance of getting in the team, especially if it really is your field of expertise.
To explain why "easy" problem is hard, the best way I found is to find a precedent. Like "remember that supposedly easy project that ended up costing so much money to the company, that's what you are asking me right now, I can do it, but don't expect a different result", or "No, I can't finish it by 10pm, last time it took 3 days, it will also take 3 days this time, if you want it to be done by 10pm, find someone better than me or reduce the scope". The goal, if you get the task, is to make it clear it is harder than it looks (bonus point if it isn't).
With one-off tasks, you get to learn a lot in many fields. Being a jack of all trades is interesting too. "Interesting" work can become stale if you are doing it for too long. You may think that spending all day working on a state-of-the-art project that make inspiring YouTube videos is interesting, but it can quickly become routine. But if you are recognized as a wild card, you can get to work for some time on that fancy project, maybe just because there is a library that crashes or because they need you do whip out a quick UI, but you get to see the environment, work a bit, and see if it is as interesting as it looks, and if it is, and if you really saved their ass, you have your chance of getting in the team, especially if it really is your field of expertise.
They wont let you work on the interesting projects because they can get much more value out of you doing other work.
Write down everything you've accomplished, including the stuff others have got credit for, and also the things you got blamed for, and word it like "was responsible for" and "learned".
And be a bit "humble" about others stealing the credit, instead of "I did not get the credit I deserve", say "It was Joes idea, I just wrote the prototype, evaluated the market, launched the MVP, talked to customers, iterated on and improved the product, helped it grow to 2 million recurring monthly revenue, and helped it expand into five continents, and I trained the staff that is now working on it. But all credit goes to Joe for coming up with the idea and inspiring me to work hard, and the new staff for doing such a good job"...
Make sure everyone know what you can do. Then find another job. People will talk, and they will say - yeh he did all those things, wow.
The only way to make everyone around you change is to change to another company, with a new picture of what you can accomplish.
Write down everything you've accomplished, including the stuff others have got credit for, and also the things you got blamed for, and word it like "was responsible for" and "learned".
And be a bit "humble" about others stealing the credit, instead of "I did not get the credit I deserve", say "It was Joes idea, I just wrote the prototype, evaluated the market, launched the MVP, talked to customers, iterated on and improved the product, helped it grow to 2 million recurring monthly revenue, and helped it expand into five continents, and I trained the staff that is now working on it. But all credit goes to Joe for coming up with the idea and inspiring me to work hard, and the new staff for doing such a good job"...
Make sure everyone know what you can do. Then find another job. People will talk, and they will say - yeh he did all those things, wow.
The only way to make everyone around you change is to change to another company, with a new picture of what you can accomplish.
Yup, I call that the 'convective derivative'[0] rule: "the best way to change the people around you is to change which people are around you."
[0]https://en.wikipedia.org/wiki/Convective_derivative
[0]https://en.wikipedia.org/wiki/Convective_derivative
> SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!!
Or find new management, if this is a consistent problem.
Unless you happen to be the management hiring boss, that means finding a different place to work.
Or find new management, if this is a consistent problem.
Unless you happen to be the management hiring boss, that means finding a different place to work.
This is really easy to say, but having done pretty much exactly this for ages, finding management that doesn't take advantage of you in this regard is really rare.
I agree finding good management is a hard problem. It's also a very important one for engineers to solve.
If you don't put effort into finding management that you work well with, you probably won't find it.
If you don't put effort into finding management that you work well with, you probably won't find it.
The problem is that management is free to tell you all these beautiful fantasies about work culture during the hiring process. There's absolutely no way for candidates to see if it's true or not.
So in that regard, I disagree. Candidates don't need to "solve" the problem of recruiters completely misrepresenting the workplace.
So in that regard, I disagree. Candidates don't need to "solve" the problem of recruiters completely misrepresenting the workplace.
Here what's worked well for me:
Always try to be a good coworker. Be helpful, friendly and competent.
If you do this well, you'll leave be 5-10 coworkers who are happy to recommend you at each job. They will also tell you the truth about culture where they work.
That's pretty much how I have done it.
BTW, one trick to learn the real culture is to ask engineers - not managers - during one on one interviews. Few engineers will lie to a potential future coworker in private.
Always try to be a good coworker. Be helpful, friendly and competent.
If you do this well, you'll leave be 5-10 coworkers who are happy to recommend you at each job. They will also tell you the truth about culture where they work.
That's pretty much how I have done it.
BTW, one trick to learn the real culture is to ask engineers - not managers - during one on one interviews. Few engineers will lie to a potential future coworker in private.
That's not true. People lie all the time to prevent backlash against them.
I feel your pain.
On one small thing. I've started asking people where they want to be on the fast / polished scale.
I've always struggled with this. Have budget for a prototype, call is a prototype through speccingand end up with a client complaining it doesn't do everything perfectly. That's on me for not being clearer which is why I'm trialling the scale above. See how it goes!
On one small thing. I've started asking people where they want to be on the fast / polished scale.
I've always struggled with this. Have budget for a prototype, call is a prototype through speccingand end up with a client complaining it doesn't do everything perfectly. That's on me for not being clearer which is why I'm trialling the scale above. See how it goes!
There is a bright side to this - you're also rather important to the company. You're in effect the 1 in "bus factor 1" of several key activities that nobody else wants to do and nobody else is really qualified to do. This should allow you to put your foot down more often, refuse overtime, demand recognition for contributing to prototypes and to be given more interesting work. Your managers may not care for you, but they care for the company (unless it's one of those cash burning shops, but that's an entirely different problem). After long enough, they should even come around to the idea of hiring a junior dev under your supervision and training to take care of the more lower-level tasks.
Painful experience has taught me that the solution to this problem, being surrounded by people who don't take me seriously, is only to break out from them and leave them forever behind. Years can be taken from you by inactivity in this regard.
In my experience, as an employee (with no real skin in the game), doing the unglamorous jobs rarely gets rewarded with anything but more unglamorous work. You have to fight for your career and be willing to switch roles or jobs when you recognize when you've hit a glass ceiling. If I was told no to a project I (a) wanted to work on, (b) was qualified for, and (c) needed to be done, I would be looking for a new job. Whatever "social equity" I've given up for a new job has always been worth it.
don't volunteer for the one-off quickies, either.
they'll keep coming to you.
they'll keep coming to you.
A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit[1].
Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. The key is you need to write and debug a little at a time.
Case in point, I wrote an entire Wasm interpreter[2] in x86-64 asm over the past few months. I wrote it a little at a time, had lots of unit tests, and am working in an engine that was already completely functional (with a slower interpreter).
[1] If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail. If you find yourself writing more than a few thousand assembly instructions, total, you have probably have already failed.
[2] https://github.com/titzer/wizard-engine/blob/master/src/engi...
Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. The key is you need to write and debug a little at a time.
Case in point, I wrote an entire Wasm interpreter[2] in x86-64 asm over the past few months. I wrote it a little at a time, had lots of unit tests, and am working in an engine that was already completely functional (with a slower interpreter).
[1] If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail. If you find yourself writing more than a few thousand assembly instructions, total, you have probably have already failed.
[2] https://github.com/titzer/wizard-engine/blob/master/src/engi...
Isn't it better to write the entire thing in a higher level language like C first, then start optimizing the slow parts e.g. by writing them in assembly?
Sometimes writing asm is just to get access to certain instructions or states not exposed in C. Particularly on embedded platforms. But generally, I agree that you should write most, if not all, in a higher-level language first.
For all our embedded work, we first prototype (something we always call a simulator which it kind of is) in typescript (used to be c#), then port to c => if we need 'less' (the c version is too big, too slow etc) we port it to asm. The advantage of this way is that we already know it meets the demands of the business (because we fleshed that out with the typescript version) and we have a low level version (c) that corresponds in functionality as we can test the 2 versions in the same way. Moving to asm is still a pain, but far less painful than other ways we tried in the past (like when I did a lot of straight to asm in the 80s, which was very painful, but there was no real way, except for some algorithms, to do the 'simulator' step here).
> If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail
Why? (asking as somebody who wrote a lot of asm)
Why? (asking as somebody who wrote a lot of asm)
I find that I make a lot of mistakes with asm. When you've written hundreds of asm instructions in one change, because of debugging is superlinearly hard, one can easily spend a lot of time debugging. So now I write and commit in small chunks and test repeatedly. This has made me much more efficient by drastically reducing the time searching for where in the hundreds of instructions I've gone wrong.
What the author is outlining is a management paradox when managing by indicators, combined with some egotrippin'.
It is hard to punish people for working hard and fixing something, when they are fixing something they created that was crappy from the start! And then the team that is highly-tuned and made a perfect design from the start shows very little improvement because it is already perfect. The indicators flip the script and make it hard to decide who actually deserves accolades. The correct answer is that they both do: one team for figuring out their mess, the other team for executing flawlessly. But the flawless people, in my experience, tend to have big egos and are offended by the seemingly equitable treatment.
The part about ego trip is the "always looking out for yourself." On the one hand, you have to promote yourself, on the other hand, you're part of a team. And manipulating the system to make to make sure you get preferred assignments backfires spectacularly. Which is why those folks tend to switch companies a lot.
I'm ambivalent about this. It can be taken as some tips as how to be be assertive by not getting shafted by evildoers like the author (remember that debate from last week on HN?), which are healthy. But there's also a lot of "me first" that'll get you shivved in the long run.
It is hard to punish people for working hard and fixing something, when they are fixing something they created that was crappy from the start! And then the team that is highly-tuned and made a perfect design from the start shows very little improvement because it is already perfect. The indicators flip the script and make it hard to decide who actually deserves accolades. The correct answer is that they both do: one team for figuring out their mess, the other team for executing flawlessly. But the flawless people, in my experience, tend to have big egos and are offended by the seemingly equitable treatment.
The part about ego trip is the "always looking out for yourself." On the one hand, you have to promote yourself, on the other hand, you're part of a team. And manipulating the system to make to make sure you get preferred assignments backfires spectacularly. Which is why those folks tend to switch companies a lot.
I'm ambivalent about this. It can be taken as some tips as how to be be assertive by not getting shafted by evildoers like the author (remember that debate from last week on HN?), which are healthy. But there's also a lot of "me first" that'll get you shivved in the long run.
My favorite is the times when I have dived in to fix performance of the system, found the place where I or a team mate left in a terribly unnecessary loop or increased complexity, quickly fix that and report back the great success in improving performance! Great indicator there for management.
I think the person/team following such a path does deserve accolades but if their ego blocks them from admitting honestly how difficult the work was, others will sense (maybe not management) the dishonesty sooner or later and problems will eventually develop.
I always give my team mates accolades and offer them excuses when they've messed up: "we were really busy that week", "its easy to forget to bump the minor version", "that manual testing work is tough". If they choose to ignore the offered excuse and go silent with their ego I think it stands out sorely over time. If they accept it then we all know what we have to improve on next time.
I think the person/team following such a path does deserve accolades but if their ego blocks them from admitting honestly how difficult the work was, others will sense (maybe not management) the dishonesty sooner or later and problems will eventually develop.
I always give my team mates accolades and offer them excuses when they've messed up: "we were really busy that week", "its easy to forget to bump the minor version", "that manual testing work is tough". If they choose to ignore the offered excuse and go silent with their ego I think it stands out sorely over time. If they accept it then we all know what we have to improve on next time.
> I always give my team mates accolades and offer them excuses when they've messed up: "
I like that a lot!
Engineers almost always know when they've screwed up. No need to thunk people over the head: I've been thunked (and screamed at, and threatened, and humiliated) so many times that I made sure that bullshit ended with my management style.* Unless they do it repeatedly, or are totally unaware... those are some of the worst types of situations for me personally as a manager.
* to the best of my knowledge: blindspots abound, esp. across cultures.
I like that a lot!
Engineers almost always know when they've screwed up. No need to thunk people over the head: I've been thunked (and screamed at, and threatened, and humiliated) so many times that I made sure that bullshit ended with my management style.* Unless they do it repeatedly, or are totally unaware... those are some of the worst types of situations for me personally as a manager.
* to the best of my knowledge: blindspots abound, esp. across cultures.
Since I started working as a “consultant”, I started using the exact same Evildoer tricks ! I’ve said “No” to partners coming with easy & urgent requests, just because I wasn’t feeling like dropping my work and doing these. To the juniors’ disbelief, I _gained_ their respect.
This is also how I never got caught with the “can you stay all night/all weekend and try to get this done before monday ? Our boss just asked for it..” song. Nope, he’s just being evil. I have other plan, good luck.
This is also how I never got caught with the “can you stay all night/all weekend and try to get this done before monday ? Our boss just asked for it..” song. Nope, he’s just being evil. I have other plan, good luck.
I imagine this works as long as you can say no, requiring good financial management and marketing skills. Easy to say no when you are turning away work.
That's also another positive feedback loop between being "evil" and a consultant job.
If your work is perceived as "hard" and you let your client do the "easy" part, then you can increase your fees (bigger impact, and more ownership for them). If your fees are higher than normal, then your client doesn't want to bother you with the "easy" stuff. You get hired to do the "hard" things. Doing "hard" things often involve saying no to spurious/out of scope requests. Etc etc...
If your work is perceived as "hard" and you let your client do the "easy" part, then you can increase your fees (bigger impact, and more ownership for them). If your fees are higher than normal, then your client doesn't want to bother you with the "easy" stuff. You get hired to do the "hard" things. Doing "hard" things often involve saying no to spurious/out of scope requests. Etc etc...
It works both ways as a positive feedback loop.
A lot of wisdom here. The hard things are almost always more fun than the easy things anyway.
> To get away with postponing, you need an excuse: other supposedly urgent work;
This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.
> To get away with postponing, you need an excuse: other supposedly urgent work;
This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.
Yes, there are a lot of dysfunctional organizations out there.
That's a strategy that might yield short term financial success and entertainment value, but it's probably not helping out the organization.
That's ok. It's not hard to find organizations to work at such that not helping them out is either not really harming or actually improving the world
I mean, outside of small-startup environments, who cares?
Do I have a moral responsibility to care? Maybe. Do I have a real reason to care outside of that tenuous-at-best ethical reason? If you believe the author's piece, no.
>but it's probably not helping out the organization.
If this strategy is useful, the organization doesn't care about you anyway.
If this strategy is useful, the organization doesn't care about you anyway.
I’m here to make a buck for myself, not help the organization raise shareholder value.
It's funny you have this nice paying job but it becomes a lull/drag idk shouldn't complain.
> Under time pressure, the scope shrinks
You may call it evil but I call it building the things that actually need to get done.
You may call it evil but I call it building the things that actually need to get done.
I'd bet a huge amount of "pro skills" is having a sense of balance between time-to-implement / feature-value. And design stuff that allows for slight additions without going full-blown NIH framework
“How to make this work within constraints” and “When to suggest alternatives with better constraints that require smol tweaks in requirements” is the whole point of engineering.
“Build whatever they ask” is … eh it’s not what engineering is about. You have to be a partner, an expert. Can’t expect the suits to know everything, that’s what they hired you for.
“Build whatever they ask” is … eh it’s not what engineering is about. You have to be a partner, an expert. Can’t expect the suits to know everything, that’s what they hired you for.
The thing is, at least in my experience, until you work for someone (and especially alone) you have no feel for what constraints are. Especially in programming today.. we have almost infinite compute power and storage (unless you develop something very very demanding) so it's so easy to go wild.
My only lone "pro" gig (and from scratch) I gained a knowledge about what is critical to make your project coast smoothly and how nothing else matters at all. You want clear / small / predictable changes toward a goal that can make you feel finished and solid rapidly. Unlike the neverending projects reboot with grandiose attempts at pure abstractions, that I used to do.
My only lone "pro" gig (and from scratch) I gained a knowledge about what is critical to make your project coast smoothly and how nothing else matters at all. You want clear / small / predictable changes toward a goal that can make you feel finished and solid rapidly. Unlike the neverending projects reboot with grandiose attempts at pure abstractions, that I used to do.
So much this
Simply prioritizing tasks correctly is all you really need to do.
If you can't figure out what is important or not, default to order by descending difficulty. Get the team on a call and figure out hardest, 2nd hardest, 3rd hardest, and then assign those tasks.
You will likely (but not always) find the trivial, "easy" shit wasn't that valuable to begin with - otherwise it would have been prioritized by the business and have been completed already.
There are additional benefits with this approach - If the whole team starts knocking out the scariest shit first, it's like paying off your biggest debt first. The psychological power of that is really hard to overstate in my experience.
If you can't figure out what is important or not, default to order by descending difficulty. Get the team on a call and figure out hardest, 2nd hardest, 3rd hardest, and then assign those tasks.
You will likely (but not always) find the trivial, "easy" shit wasn't that valuable to begin with - otherwise it would have been prioritized by the business and have been completed already.
There are additional benefits with this approach - If the whole team starts knocking out the scariest shit first, it's like paying off your biggest debt first. The psychological power of that is really hard to overstate in my experience.
Uncertainty is huge in innovating. If nobody's done it before, it's hard to know if it will actually work. That's the part that needs to get done first.
If you hire a consulting agency and for some reason they prioritize the easiest and most known task...
You still have no evidence they can complete the hard thing.
If you hire a consulting agency and for some reason they prioritize the easiest and most known task...
You still have no evidence they can complete the hard thing.
Whatever one thinks of the techniques recommended in this article, the perils of working on a "easy" but in actuality hard problem are not to be overstated.
The dreaded 3 point story that takes 3 weeks.
...yeah been there.
...yeah been there.
This is why I always severely overestimate the length of my tickets.
1. I am usually never behind schedule 2. I look like a hero when I deliver on time
1. I am usually never behind schedule 2. I look like a hero when I deliver on time
"We do these things not because they were easy, but because we thought they would be easy."
I actively try to avoid to do anything the easy way, because I know ill get bored if do. Motivation is the most valuable resource in programming. I rather do something over engineered that I find interesting, then something simple and boring. Even if it takes 3 times the effort, I know ill put more than 3 times the effort in if I'm motivated, and ill end up learning something and ill end up with something I'm proud of, something worth talking about.
Sounds like you’ll end up with something 3x as hard for future engineers to maintain also.
Why? You were given no suggestion in which dimenension the complexity was introduced in. Frequently, the better design requires the additional effort.
Its the quick hacks and shortcuts that accumulate debt fastest.
Its the quick hacks and shortcuts that accumulate debt fastest.
(Or yourself to maintain in a year's time)
... but also 3x the job security, perhaps?
Beats not doing it at all.
I can't tell if this is sarcasm or not. If serious ...
This seems like a reckless way of regulating your motivation at work IMO. I don't mean to be snarky. But it really does put a lot of risk and cost on your colleagues, doubly so if you're leading a team, /and/ puts a lot of risk on your own career and reputation.
If you need to over-engineer everything to stay motivated, you need a different job. A job where the _problems_ are hard and the challenge is to find simple solutions to them, instead of the other way around.
This seems like a reckless way of regulating your motivation at work IMO. I don't mean to be snarky. But it really does put a lot of risk and cost on your colleagues, doubly so if you're leading a team, /and/ puts a lot of risk on your own career and reputation.
If you need to over-engineer everything to stay motivated, you need a different job. A job where the _problems_ are hard and the challenge is to find simple solutions to them, instead of the other way around.
Who said i don't already have that job?
You said it.
"My job doesn't stretch me."
"Why don't you get a job which stretches you?"
"Who said I don't have a job which stretches me?"
"My job doesn't stretch me."
"Why don't you get a job which stretches you?"
"Who said I don't have a job which stretches me?"
Please don't do things like this, it makes it harder for your team. Find the challenge outside your work if you need it. Just do it the straightforward way.
Agreed. I often see this kind of work from some developers and I always have to send it back. People who think the best way to fix a minor bug is to rewrite the whole system or to stick on a second system that duplicates loads of logic.
Sure, if the task is to rip the system to shreds and improve it, go ahead. But often I look in to it and see the problem can be solved by fixing a single line that was wrong.
Sure, if the task is to rip the system to shreds and improve it, go ahead. But often I look in to it and see the problem can be solved by fixing a single line that was wrong.
Sounds like you need to be more picky, to get the jobs that genuinely require that level of engineering. I’d find it hollow to add all that complexity when not needed.
> Motivation is the most valuable resource in programming
I've never seen it phrased like this before, but I like it and there's truth to it.
I've never seen it phrased like this before, but I like it and there's truth to it.
[deleted]
Easy things appear hard to upper management. Hard times appear to be easy. Then you see a bunch of people getting promoted by working on "hard" things while you are left dealing with "easy" things. Good leadership senses this dichotomy. There are also things you cannot tell anyone in sufficient detail how difficult they are and no matter what you do - they always appear to be easy. Everytime I pickup a hobby, I underestimate it. By a lot. The depth and endeavor for human expertise never ceases to amaze me. You're alone a lot of times and I find solace in the fact that my brain is a machine that takes calories as input and produces heat + code. Might as well try to take on hard things regardless of what others think of it. I'll be left with a real kick of pleasure by solving problems than fake titles obtained by excessive misuse of vocal cords.
I have different attitudes around things perceived as easy or hard. Things that are considered by many to be easy I pay extra attention to looking for details that may show it's not really easy to do properly.
Hard things I think and rethink to see if there's an easy approach or conceptualization that does less or something different achieving the same end goal.
As others have said, I also gravitate toward the hard stuff because it's more interesting. And if there's a complicated way of automating or otherwise have the machine do the work instead of myself, even if it takes longer and may only do once is still a good learning/hacking opportunity. Sometimes cool stuff comes out, like a partial Swift -> Java, or Java to C++ translator because I don't want to rewrite a suite of tests.
Hard things I think and rethink to see if there's an easy approach or conceptualization that does less or something different achieving the same end goal.
As others have said, I also gravitate toward the hard stuff because it's more interesting. And if there's a complicated way of automating or otherwise have the machine do the work instead of myself, even if it takes longer and may only do once is still a good learning/hacking opportunity. Sometimes cool stuff comes out, like a partial Swift -> Java, or Java to C++ translator because I don't want to rewrite a suite of tests.
> So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want.
OMG this is sooo true, my first company does not have any product manager or project manager. My boss who is one of the management always try to "impress" other management by saying yes to some stuff that they challenge him: "can you do it?", then he would say "yes it will be finished in 2-3 days", and then he would come to me and say "we need to impress them", again and again until i'm sick of it because we just went away from our sprint and planned projects.
Stupidly, I just did it again and again. Luckily I quit before I hated him, but then my teammates are still there.
best of luck tot hem
OMG this is sooo true, my first company does not have any product manager or project manager. My boss who is one of the management always try to "impress" other management by saying yes to some stuff that they challenge him: "can you do it?", then he would say "yes it will be finished in 2-3 days", and then he would come to me and say "we need to impress them", again and again until i'm sick of it because we just went away from our sprint and planned projects.
Stupidly, I just did it again and again. Luckily I quit before I hated him, but then my teammates are still there.
best of luck tot hem
I think most people get into hard "easy" problems not because they want, but because those problems usually have a lot of opening positions.
Low level programming, on the other side, does not have a lot of openings. The majority have to do those hard "easy" problems for their life.
Low level programming, on the other side, does not have a lot of openings. The majority have to do those hard "easy" problems for their life.
This is the work of a modern Machiavelli.
In my experience these 'evil' things are rather common practice. People do far more nasty stuff to get ahead, all the time. Programmers are no exception.
This blog is amazing. I currently find myself in some sort of a conflict with management over the classic "new-features vs make the thing stable" situation. Management openly admits to valuing tech debt repayment, reliability etc. but I can clearly tell that it is not what is actually valued.
And why shouldn't I just skip code reviews, skip analyzing failure scenarios. Just churn out new shit at an "amazing pace" with little regard to fulfilling the harder part of the target objectives of the system.
http://yosefk.com/blog/people-can-read-their-managers-mind.h...
We'll try to fix it when shit actually hits the fan, when the harder to achieve properties of the system are considered urgent again :)
(Just to make it clear: I am not working on medical devices or power plants or anything of this sort).
And why shouldn't I just skip code reviews, skip analyzing failure scenarios. Just churn out new shit at an "amazing pace" with little regard to fulfilling the harder part of the target objectives of the system.
http://yosefk.com/blog/people-can-read-their-managers-mind.h...
We'll try to fix it when shit actually hits the fan, when the harder to achieve properties of the system are considered urgent again :)
(Just to make it clear: I am not working on medical devices or power plants or anything of this sort).
One thing that annoys me is that if you carefully craft a complex subsystem that behaves well in prod that does not get noticed much. On the other hand a quickly thrown together something that requires heroic efforts to keep running and make stable might get much more noticed.
Yea maybe if managers didn't pressure so hard on new features when they know 100% that there are so many bugs needing fixing + tests need writing, and general stability issues.
Shit will hit the fan but that's how they are directing the course of the ship, early in my career I just have to go with it right now It is not worth it for me to try doing the "easy" things when they aren't valued..
Working like this is too stressful though even if you look like a hero.
Shit will hit the fan but that's how they are directing the course of the ship, early in my career I just have to go with it right now It is not worth it for me to try doing the "easy" things when they aren't valued..
Working like this is too stressful though even if you look like a hero.
"If you do too much people get dependent on you. And if you do nothing, they lose hope…when you do things right, people won’t be sure you’ve done anything at all.”
~ God (Futurama)
~ God (Futurama)
> One thing you want to prevent is people learning to remind you earlier. The way to accomplish it is being very nice when they come late. If people feel punished for reminding too late, they'll come earlier next time, and in a vengeful mood, so with more needless tasks. But if they're late and you eagerly "try to do the best under the circumstances", not only do you put yourself under the spotlight as a patriotic hero, you move the forgetful culprit out of the spotlight. So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want.
This speaks to another effective career strategy, which is to focus on making the people you interact with feel good - about you, the situation, the company you work for, and especially about themselves. This is particularly important with first impressions and for people with whom you don't work very often.
"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." - Maya Angelou
This speaks to another effective career strategy, which is to focus on making the people you interact with feel good - about you, the situation, the company you work for, and especially about themselves. This is particularly important with first impressions and for people with whom you don't work very often.
"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." - Maya Angelou
Maybe? Sometimes? But the article seems to imply a very high level of control over the tasks & projects that come your way.
In reality, I (and probably a lot of people) don't have that choice. I end up looking like a hero when I can deliver quickly on a "hard" easy thing, and look like I'm slacking off when an "easy" hard thing comes my way. Fortunately I have had bosses who listen when I explain the difficulties of a project, but they still get frustrated on occasion when an ostensibly simply task snowballs into something massive more complex once you dig into the details.
In reality, I (and probably a lot of people) don't have that choice. I end up looking like a hero when I can deliver quickly on a "hard" easy thing, and look like I'm slacking off when an "easy" hard thing comes my way. Fortunately I have had bosses who listen when I explain the difficulties of a project, but they still get frustrated on occasion when an ostensibly simply task snowballs into something massive more complex once you dig into the details.
I’ve had first-hand experience confirming this and another field. Sometime in my 20 years of artistic glassblowing, I believed that people where to find it moderately impressive if I made intermediate level work very solidly with a flourish. I thought this was an alternative to making work that was more overtly at a higher skill level, and a better choice than making less solid work reaching above my skill level. It turns out that as the article states, working on anything cutting edge, especially ambitious publicized projects, would have been much better for gaining notoriety.
at a job once we had a programmer do a gratuitously bad implementation that wasted over $400k of cloud spend. They got promoted for fixing it the following half.
My project that quarter continues to run multiple years later without a hiccup. Much like they do with me, they often forget it exists.
Law 6 Court attention at all costs - https://alexanderemmanual.medium.com/law-6-court-attention-a...
My project that quarter continues to run multiple years later without a hiccup. Much like they do with me, they often forget it exists.
Law 6 Court attention at all costs - https://alexanderemmanual.medium.com/law-6-court-attention-a...
I really like this advice and always op for the hard way, the way that solves things preferably for many others, once and for all in an elegant way.
At work, you have time to dive into stuff, for hours on end with little interruption. Very different from at home, with your hobby projects. I see work as a place where I do indeed solve very hard problems because I just have a massive amount of time and focus to spend there.
At work, you have time to dive into stuff, for hours on end with little interruption. Very different from at home, with your hobby projects. I see work as a place where I do indeed solve very hard problems because I just have a massive amount of time and focus to spend there.
I love when someone puts this kind of thought and philosophy behind some of the crazy choices we are making subconsciously every day.
While I do get the point, I feel like this works only for people having regular jobs, e.g. being paid for their time.
If you're a researcher for example bashing at that hard(but often popular) thing will probably yield little to no results. On the other hand going for paths unknown might feel riskier, but has the potential of uncovering low hanging fruit. Just my 2c.
If you're a researcher for example bashing at that hard(but often popular) thing will probably yield little to no results. On the other hand going for paths unknown might feel riskier, but has the potential of uncovering low hanging fruit. Just my 2c.
Heh, I think this applies to pretty much everything and everyone. For most people, anything you haven't done yourself or know in great detail, you will not be able to gauge how hard it is. And sometimes what people are calling hard is actually very easy for a certain set of people. So its all relative anyway.
For me, it works the same way even if others are not involved. If I do a tricky thing in a matter of hours because I got lucky I tend to feel happier about it compared to if I’ve done a simple but mundane thing over the weekend. Perceived complexion brings excitement.
Working on hard problems isn’t always a rewarding path. I’ve seen plenty of very senior engineers get sucked into difficult problems with no additional resourcing only to be all but forgotten by the rest of the team.
I agree that working on easy problems is not worth your time though
I agree that working on easy problems is not worth your time though
[deleted]
Sounds like a normal day in office.
[deleted]
Coincidently I was thinking the other day if I learn kubernetes, azure services and networking to a decent level, I might have a nice source of easy hard things in the future (most coders don’t seem super keen on this kind of stuff)
Effort estimation in agile development is supposed to solve this right? Does it not in practise? I'm not a developer, I've just heard of agile so I don't really know how its actually done in a big software org
No, because it's often very hard to estimate until you're actually working on something. It's common to get a consensus estimate that something is "easy" only for some poor developer to be left with something that is "hard" and takes much longer than estimated.
Also, something might genuinely be easy for someone who has worked on that part of the codebase before. But it could take someone new a long time to get up to speed, again making that developer look bad (this is not to advocate that only devs familiar with the code should work on it - you want to spread the knowledge around).
Also, something might genuinely be easy for someone who has worked on that part of the codebase before. But it could take someone new a long time to get up to speed, again making that developer look bad (this is not to advocate that only devs familiar with the code should work on it - you want to spread the knowledge around).
I learned this long ago.
Along with: you will never be thanked for getting a garbage project across the line. You will be thanked more for having a small part in a good project than being the hero on a garbage project.
Along with: you will never be thanked for getting a garbage project across the line. You will be thanked more for having a small part in a good project than being the hero on a garbage project.
This works until your boss understands software development
If your boss understands software development, then the "dangerous" situation of being asked to do "easy" (but actually hard) things disappears, because your boss will understand that the "easy" things are actually hard, and the "hard" things are actually easy.
I agree! This is the case with my boss and its a great work environment
spoiler: if your boss understands this they 1) are not doing their jobs 2) they will fail hard if they try to push their own thinking on HOW to do things
Interesting. To be clear I'm a developer and my boss is a director of application development. He used to be a dev so he understands these kind of issues.
If my boss was a product owner or a stakeholder I would not want them mandating random details about how I do things.
If my boss was a product owner or a stakeholder I would not want them mandating random details about how I do things.
I could be more productive using my own frameworks to build stuff but I don't think I'll get paid for it though. Such is life.
the problem is managers who know a little about programming thinking everything is "easy" and declaring as much to marketing
This is bullshit. There are any number of 'easy' things that need to get done. The discipline in being a grown up no bullshit engineer is to do all of these easy things well, without errors and with appropriate test coverage. If you are in my team, I will appreciate and reward your maturity and attention to detail. What I don't want is somebody who always want's to work on the 'interesting' problem at the expense of the small stuff. grow up.
You might appreciate it but not everyone does. Also there is a Matthew effect in play - the more boring stuff you do the less chance you have to do something interesting in the future. Because everyone on the market wants you to have experience with things similar to what they are about assign you to.
I agree with you, though sadly HN doesn't. Some days you're just beating your skull against a brick wall recompiling 3rd party libraries till 5pm, some days you get to write the big exciting part. That's life. That's the job. Accept it or move on.
This is hilarious, and cynical, and contains a legit kernel of wisdom.
Eh, not really, it sounds like one of those Robert Greene BS books. Sounds exciting when you're young and inexperienced, but tiresome when you're older and actually wise
Ha! Did your comment make you feel better about yourself? Was it representative of the kind of wisdom you value? Because it came across as a misdirected, failed attempt at an insult.
Sounds like hard work..
Complexity of tasks doesn't matter to the business, only the impact of completing them.
If a client wants X or won't sign a contract worth $Y then the tasks to complete X become valuable regardless of their complexity.
If a client wants X or won't sign a contract worth $Y then the tasks to complete X become valuable regardless of their complexity.
Obligatory XKCD which brilliantly captures how management can fail to distinguish easy/hard tasks: https://xkcd.com/1425/
Am I the only one having a hard time understanding what he's saying? Somehow it just feels like a hodgepodge of words.
> and you let them fail a few times, and you wait until they come back with a readjusted attitude - that's evil.
What, no?
Letting ignorant people fall on their knives is /doing good/. It's the best way of learning.
Letting ignorant people harm others - that's evil.
What, no?
Letting ignorant people fall on their knives is /doing good/. It's the best way of learning.
Letting ignorant people harm others - that's evil.
The Elon Musk Doctrine
'easy' and 'perceived' as easy are different things.
Things that are perceived as hard, usually are way harder, and you're set up to fail.
Since corporations don't like failure, even when it's expected, it's a tough choice that mingles up the author's logic.
I'd argue the 'easy thing done' counts more because you 'got it done' and the complexity is a second order factor.
It's one of the things I'm always on the lookout for actually, is to try to ascertain really what's going on.
The added challenge, is that sometimes 'bad devs' make things necessarily complex out of stupidity, and 'brilliant devs' often do the same out of adding on unnecessary complexity.
It takes a lot of oversight to tell, and it's almost impossible to guess at from the outside.
Things that are perceived as hard, usually are way harder, and you're set up to fail.
Since corporations don't like failure, even when it's expected, it's a tough choice that mingles up the author's logic.
I'd argue the 'easy thing done' counts more because you 'got it done' and the complexity is a second order factor.
It's one of the things I'm always on the lookout for actually, is to try to ascertain really what's going on.
The added challenge, is that sometimes 'bad devs' make things necessarily complex out of stupidity, and 'brilliant devs' often do the same out of adding on unnecessary complexity.
It takes a lot of oversight to tell, and it's almost impossible to guess at from the outside.
I also worked on my own (with the exception of some nginx issues) on a feature to keep an in browser file browse up to date for all users via web sockets. This was really a view on a git repo accessed through the Gitlab api, it was a nightmare to deal with because of the way Git tracks (or doesn’t really) folders. This feature was seen to be easy and I slaved on it for days and eventually weeks because of edge cases and feature creep to no kudos or compliments. Which is fine, it’s my job.
It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.