This works until your boss understands software development
> This works until your boss understands software development Like that ever happens!
haha! yeah, its rare but my company promotes devs to director positions so it can happen
Evil programmer's tip: avoid “easy” things (2016)
191–200 of 203 posts
Re: Evil programmer's tip: avoid “easy” things (2016)
#192This works until your boss understands software development
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.
this is the truth
Re: Evil programmer's tip: avoid “easy” things (2016)
#193This works until your boss understands software development
If your boss understands software development, then the "dangerous" situation of being asked to do "easy" (but actually hard) things disappears, because your boss will understand that the "easy" things are actually hard, and the "hard" things are actually easy.
I agree! This is the case with my boss and its a great work environment
Re: Evil programmer's tip: avoid “easy” things (2016)
#194This works until your boss understands software development
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.
Re: Evil programmer's tip: avoid “easy” things (2016)
#195Earlier quoted context omitted.
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" i…
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.
"Effort Asymmetry". That is a fantastic phrase and is so true.
Re: Evil programmer's tip: avoid “easy” things (2016)
#196Ouch. 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…
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" i…
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.
- 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
Re: Evil programmer's tip: avoid “easy” things (2016)
#197Am I the only one having a hard time understanding what he's saying? Somehow it just feels like a hodgepodge of words.
Re: Evil programmer's tip: avoid “easy” things (2016)
#198This 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…
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.
Re: Evil programmer's tip: avoid “easy” things (2016)
#199Earlier quoted context omitted.
"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 t…
What metaphor would you use though? 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.
Re: Evil programmer's tip: avoid “easy” things (2016)
#200At 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'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.
When trouble is solved before it forms, who calls that clever? When there is victory without battle, who talks about bravery?
- Sun Tzu