Heisenberg Developers (2014)
mikehadlow.blogspot.cl
Heisenberg Developers (2014)
1–10 of 193 posts
Re: Heisenberg Developers (2014)
#2This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I've done my best to actively ignore/subvert it, but it's coming up more and more.
It's incredibly stifling and frustrating and I'm really peeved. It's hard to leave a job I love and have been at for almost 5 years, but we're on a road to hell.
All that said, if anyone needs a Go dev ;)
Re: Heisenberg Developers (2014)
#3This is very true. My experience has always been that my team performed better when there were /less/ controls on their time, rather than more. I also found it was important to explain the reasons /why/ a particular thing needed to be done by a certain date, on the occasions that some external pressure needed it to be done.
People don't mind pulling out the stops and working extra hard, as long as it's occasional and /necessary/. It's absolutely morale-killing to do so for an arbitrary deadline, however. Nothing burns out a team faster than death-marches to deadlines pulled from thin air.
Re: Heisenberg Developers (2014)
#4One issue with how developers are hired these days, is many large companies are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS) and mathematical ability. Try interviewing at MS, big G or Amazon and you will see what I mean.
These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.
A potential solution to this issue, is to hire engineers with more diverse skillsets. Deep understanding of mathematics and classical algorithms is fantastic for software performance, and low level details.
On the other hand, at a tech company - your software is literally your revenue stream. You are hiring people who don't understand your business - to build and grow your business.
Maybe hire some developers with strong business skills, and a good understanding of the economy and your market - and put them on a team with more traditional engineers. In doing so, you get someone with the big picture, and someone with the details working together and might not even need another PM.
Just my thoughts.
Re: Heisenberg Developers (2014)
#5One issue with how developers are hired these days, is many large companies are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS) and mathematical ability. Try interviewing at MS, big G or Amazon and you will see what I mean. These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hack…
That sounds like a good idea, until you realize that developers with a strong grasp of coding AND business are rather rare. If you're a growing business, it's hard enough to find enough really good devs as it is, and now you want to add in another, orthogonal skill set? Good luck with that.
Re: Heisenberg Developers (2014)
#6Many developers prefer to work like Navy Seals or Jazz Musicians. It's objectively more empowering, arguably more fun.
Some jobs require an army or a big band, i.e., a lot of coordinated precision - objectively less freedom and autonomy, arguably more tedious.
Beyond some threshold of granularity you will crush morale though.
Do what makes you happy.
Re: Heisenberg Developers (2014)
#7One issue with how developers are hired these days, is many large companies are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS) and mathematical ability. Try interviewing at MS, big G or Amazon and you will see what I mean. These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hack…
Geeky (single focus) developers are
- cheaper
- do not get distracted by politics / business
- easier to control / manipulate into lower salaries
Re: Heisenberg Developers (2014)
#8I think context is important here. What is the software you are building? Is it highly critical or possibly life threatening, like a stock exchange trading system or a aeroplane control system? Should the developers be given autonomy to speed delivery? Or should more controls be put in place to ensure delivery of the quality, validated product while possibly slowing down the delivery speed.
Re: Heisenberg Developers (2014)
#9The story begins with a new feature request that the "business" thinks is needed while the "developers" think is not. It's really hard to pick sides here without knowing more about the specifics. I've seen situations where developers are completely wrong about the business value of something and I've seen it the other way around.
If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver.
Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.
I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development.
Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.
Re: Heisenberg Developers (2014)
#10It turns out that software development is a very immature industry. We simply don't know how to judge successful software projects/developers.
In the face of that immaturity we can try all kinds of things. Personally, I do anarchist development and hope for the best. Others try cargo cult project management. Still others move to highly constrained development methodologies.