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.<p>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.<p>It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.
Ouch. This hits close to home.<p>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)<p>It's because I'm seen as a technician, not an engineer or a scientist.<p>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.<p>The big things I've accomplished, other people have _always_ gotten credit for. The things that fail, I get the blame for.<p>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.
A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a <i>little bit</i>[1].<p>Writing assembly, again, in small amounts, is <i>exactly</i> 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.<p>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).<p>[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 <i>thousand</i> assembly instructions, <i>total</i>, you have probably have already failed.<p>[2] <a href="https://github.com/titzer/wizard-engine/blob/master/src/engine/x86-64/X86_64Interpreter.v3" rel="nofollow">https://github.com/titzer/wizard-engine/blob/master/src/engi...</a>
What the author is outlining is a management paradox when managing by <i>indicators</i>, combined with some egotrippin'.<p>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.<p>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.<p>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.
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.<p>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.
A lot of wisdom here. The hard things are almost always more fun than the easy things anyway.<p>> To get away with postponing, you need an excuse: other supposedly urgent work;<p>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.
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.
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.<p>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.<p>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.<p>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.<p>Stupidly, I just did it again and again. Luckily I quit before I hated him, but then my teammates are still there.<p>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.<p>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.
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.<p>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.<p><a href="http://yosefk.com/blog/people-can-read-their-managers-mind.html" rel="nofollow">http://yosefk.com/blog/people-can-read-their-managers-mind.h...</a><p>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 :)<p>(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.<p>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..<p>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.”<p>~ God (Futurama)
<i>> 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.</i><p>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.<p>"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.<p>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.<p>My project that quarter continues to run multiple years later without a hiccup. Much like they do with me, they often forget it exists.<p>Law 6 Court attention at all costs - <a href="https://alexanderemmanual.medium.com/law-6-court-attention-at-all-costs-63132007d214" rel="nofollow">https://alexanderemmanual.medium.com/law-6-court-attention-a...</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.<p>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.<p>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.<p>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
I learned this long ago.<p>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 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.
Complexity of tasks doesn't matter to the business, only the impact of completing them.<p>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: <a href="https://xkcd.com/1425/" rel="nofollow">https://xkcd.com/1425/</a>
> and you let them fail a few times, and you wait until they come back with a readjusted attitude - that's evil.<p>What, no?<p>Letting ignorant people fall on their knives is /doing good/. It's the best way of learning.<p>Letting ignorant people harm others - that's evil.
'easy' and 'perceived' as easy are different things.<p>Things that are perceived as hard, usually are way harder, and you're set up to fail.<p>Since corporations don't like failure, even when it's expected, it's a tough choice that mingles up the author's logic.<p>I'd argue the 'easy thing done' counts more because you 'got it done' and the complexity is a second order factor.<p>It's one of the things I'm always on the lookout for actually, is to try to ascertain really what's going on.<p>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.<p>It takes a lot of oversight to tell, and it's almost impossible to guess at from the outside.