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.
Evil programmer's tip: avoid “easy” things (2016)
21–30 of 203 posts
Re: Evil programmer's tip: avoid “easy” things (2016)
#22At 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…
> 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.
He explicitly says this in the article. I think the majority of commenters only read the title.
Re: Evil programmer's tip: avoid “easy” things (2016)
#23Easy 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.
Re: Evil programmer's tip: avoid “easy” things (2016)
#24the problem is managers who know a little about programming thinking everything is "easy" and declaring as much to marketing
Re: Evil programmer's tip: avoid “easy” things (2016)
#25While 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.
Re: Evil programmer's tip: avoid “easy” things (2016)
#26I 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 o…
Sounds like you’ll end up with something 3x as hard for future engineers to maintain also.
Re: Evil programmer's tip: avoid “easy” things (2016)
#27> Under time pressure, the scope shrinks You may call it evil but I call it building the things that actually need to get done.
I'd bet a huge amount of "pro skills" is having a sense of balance between time-to-implement / feature-value. And design stuff that allows for slight additions without going full-blown NIH framework
“How to make this work within constraints” and “When to suggest alternatives with better constraints that require smol tweaks in requirements” is the whole point of engineering.
“Build whatever they ask” is … eh it’s not what engineering is about. You have to be a partner, an expert. Can’t expect the suits to know everything, that’s what they hired you for.
Re: Evil programmer's tip: avoid “easy” things (2016)
#28A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit[1].
Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. The key is you need to write and debug a little at a time.
Case in point, I wrote an entire Wasm interpreter[2] in x86-64 asm over the past few months. I wrote it a little at a time, had lots of unit tests, and am working in an engine that was already completely functional (with a slower interpreter).
[1] If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail. If you find yourself writing more than a few thousand assembly instructions, total, you have probably have already failed.
[2] https://github.com/titzer/wizard-engine/blob/master/src/engi...
Re: Evil programmer's tip: avoid “easy” things (2016)
#29Ouch. This hits close to home.
I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems)
It's because I'm seen as a technician, not an engineer or a scientist.
That's because I'm the person everyone picks for the "hey, just whip up this quick demo / generate this report / prototype this idea for me", and therefore I get critiqued when it's not fast enough / polished enough, despite it being a "drop everything and have this done by 10pm" situation every time.
The big things I've accomplished, other people have _always_ gotten credit for. The things that fail, I get the blame for.
So serious advice from someone who's too old to change it now: SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Once you start, it's a trap that's really hard to get out of and gets you nowhere career wise.
Re: Evil programmer's tip: avoid “easy” things (2016)
#30A 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.