Evil programmer's tip: avoid “easy” things (2016)
yosefk.com
yosefk.com
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.
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'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.
Just look at YouTube, lots of people comment on videos without actually watching the video despite it being right there.
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.
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.
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.
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.
Clearly there are companies praising heroic fixes, while not praising too much regular maintenance.
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.
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.
- Sun Tzu
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.
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.
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.
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.
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.
Until you get the person who questions everything, draining all your time. Then they become reliant on you, and stop thinking for themselves.
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.
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.
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))
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 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.
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).
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].
a) do any research before asking the question,
b) trying to understand the answer given or
c) doesn't follow the answer given.
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've never even heard of a junior fired for "asking too many questions".
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.
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.
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.
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.
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.
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.
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 :/
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.
Who is Wally?
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.
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.
If you don't put effort into finding management that you work well with, you probably won't find it.
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.
This can be done by either changing how you’re being perceived internally, or, the easier way: getting a different job elsewhere.
they'll keep coming to you.
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.
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.
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.
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!
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.)
- 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
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.
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.
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.
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
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.
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.
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...
Why? (asking as somebody who wrote a lot of asm)
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.
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 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.
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.
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...
> 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.
If this strategy is useful, the organization doesn't care about you anyway.
You may call it evil but I call it building the things that actually need to get done.
“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.
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.
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 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.
...yeah been there.
1. I am usually never behind schedule 2. I look like a hero when I deliver on time
Its the quick hacks and shortcuts that accumulate debt fastest.
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.
"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?"
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.
I've never seen it phrased like this before, but I like it and there's truth to it.
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.
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
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.
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).
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.
~ God (Futurama)
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
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.
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...
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.
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.
I agree that working on easy problems is not worth your time though
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.
If my boss was a product owner or a stakeholder I would not want them mandating random details about how I do things.
Like that ever happens!
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.
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.
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.