Recently news covered the “not so great” situation the Stack Overflow survey exposed about developer happiness. It looks like 80% of the developers are NOT happy about their work.
80% sounds about a lot, I am probably one of those if you ask me a direct question, but the answer is a bit more complicated. But it is not for this post.
This post is about an epiphany I recently had talking with one of my colleagues. In practice my mood switched to: “I am going to ask people that I think should have answers and if they don’t replay it means that they don’t care so why should I?”.
I know, this is a pretty bad standpoint but hey, 80% of developers are unhappy. I am not here to make you smile on this.
Do you know the efficient market hypothesis?
The efficient market hypothesis (EMH), alternatively known as the efficient market theory, is a hypothesis that states that share prices reflect all available information and consistent alpha generation is impossible.
According to the EMH, stocks always trade at their fair value on exchanges, making it impossible for investors to purchase undervalued stocks or sell stocks for inflated prices.
https://www.investopedia.com/terms/e/efficientmarkethypothesis.asp
Well, nice to make this comparison today with the market going down from a couple of days.
If we assume the same applies in a company we can say that everyone does its best to achieve a goal, each one with their own skills. When you don’t write a test because you didn’t get good requirements so you are just making it up for product to have something to showcase and speak about. Or you do not apply safeguards or limits on a new functionality because you asked multiple time if we have clue about what limit we should set you are not doing the best for your project.
You decrease your professionality and my day usually turn to a shitty one because I want to be 100% all the time! I like to code, to maintain what I write and in order to do that I sometime write tests, or spend a few hours debugging. This can make some timekeeper also called product manager (with lowercase p or m) unhappy because they read a book about moving quick and breaking things so they want me to move quicker? Let’s help them to get better!
What I am going to do instead? I am going to take those decisions, not because I am the best one to take them but because it is in my interest.
I am genuinely interesting to develop a system that is secure, reliable, maintainable, exciting to work with.
To get back to the example with limits and quotas, as a developer we know that resources don’t grow forever. If you use an in memory databases you need to manage that memory and the easy way to go is to be conservative to how much a user can actually do. If you know based on current resources that a limit needs to be set, add it yourself. If you are like me, and you think that somebody else should tell you how that you are wrong. Nobody should tell you how to do your job at your best. When every customer will reach this limit, and they will start complaining you will have in front of you some very interesting conversation! Should we scale out infra up? How do we find the required resources? Should we do some benchmarking and performance optimization?
Otherwise, on a shitty day you will also have to troubleshoot and fix a crash that you knew it was going to show up.
Are you having trouble figuring out your way to building automation, release and troubleshoot your software? Let's get actionables lessons learned straight to you via email.