At my last job I made a feature to deploy arbitrary user code (most likely a trained model in Python) to a subdomain running a JS server that could take input parameters when called at that URL and would respond with the answer from the model. This effectively cut down DS deployments from potentially days to about 45 seconds. It was seen that be hard and I had a good amount of help from our awesome devops person and worked through a number of issues with the lead dev. When this was delivered everyone loved it, lots of kudos and compliments because it was seen as hard. I felt like a bit of a fraud as I felt I had a lot of help and it really was a team effort, I made efforts to highlight this.
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.
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.
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.
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.
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.
"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.
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"
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.
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.
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.
> 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.
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.
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.
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?"
records = some_orm_thing()
some_model_ids, other_ids = map(list, zip(*records))
The answer is obvious. Some tests return no records for the ORM thing and that doesn't unpack. If you ask this type of question it makes you look bad. I'm not saying it's the end of the world or anything, but we should at least be realistic about how juniors are treated. A private, friendly slack message is much less likely to get them fired than a post in a channel or pull request.
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'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 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).
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.
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.
I will help anyone that asks but if they are just using me for quick answers and never learning anything then eventually they will use up their credits with me. I cannot do their job and mine at the same time...
> 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.
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".
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].
> 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.
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.
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.
> 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 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 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.
> 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.
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.
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.
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.
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.
> 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 :/
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.
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
You'd be amazed at how many "critical" issues disappear when you ask for these things. I personally think it is only critical because someone wants to dump the problem on you so that they can go home to their families.
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.
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.
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.
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:
- 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.
You have to break out of this cycle.
- 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.
Note: Always give credit where credit is due. If someone helps you out, let the world know how awesome they are. This will help you out in the long run because you will be known as someone that is humble, human and a growing.
> 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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).
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.
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 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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
"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.”
> 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
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.
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.
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.
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.
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
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).
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.
You just don't wake up one day and understand software development. If you do work as a software developer though, you will wake up one day and realize that you actually know very little about 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.
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.
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.
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.
'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.
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.