My organization has all kind of problems and there are lots of people trying to fix our processes, methods, tools, organization, roles, strategy, whatever. Nobody seems to have a wholesome holistic vision though. I have trouble coming up with something myself.
How would you describe a great environment for software development?
I’m interested into what aspects you consider relevant. Is it the tooling? Ex-Googler seem to have a habit of reinventing Google-internal tools, for example. Is it the team or the colleagues? With the right people, I can endure a lot. Is it the strategy? Maybe a visionary at the top (Musk, Jobs, Zuckerberg) makes the difference. Maybe it is just the pay? Netflix CEO apparently believes high salaries for top talent is essential.
At first I thought you were asking about ‘dev environment’ like software tools, and expecting to see lots of answers on the ‘emacs and zsh’ level. But this sounds like a much deeper and more difficult question, about job satisfaction. (Or is it about effectiveness, i.e. delivering best value to your employer? The two need not be entirely at odds, but don’t conflate them too blithely!)
Either way, this is something that has been studied extensively and empirically, and 100x more philosophized about. I’m partial to Daniel Pink’s Autonomy, Mastery, Purpose formulation. It’s not about software at all, it’s just about work. It’s simple, covers a lot of ground, and tries to connect the employer and employee perspectives.
The book Accelerate claims a causal (not just correlation!) relation from job satisfaction to organizational performance which is at least similar to effectiveness. (Disclaimer: the data is from self-rating surveys)
From my perspective it will depend on multiple factors.
Depending the situation of your life, you will give more to one of the aspects.
Let’s start with the tiniest bit and try to see the world from the grains of sand.
All devs get a Linux laptop.
Why Linux? Because that is where power tooling lives.
Why Linux? Because it shrinks the user/dev divide.
Why Linux? Because it engages understanding and does not condescend.
Why Linux? Because it is flexible enough to take on your task (iOS devs, put the pitchforks down. iOS is an outlier).
Why Linux? Because it occupies a socio-technical place where tools and building tools on tools is prized, and what is the end software, if not a tool?
What do we learn from Linux?
That you, too, can be powerful and capable.
Who do we hire? Those interested in being powerful, capable, invested in their tools.
What physical environment do you supply? The one which permits configuration and customizing to the developer’s taste.
What constraints do you enforce? The ones which are required for the mission to complete, no more.
We can also learn that being paid for our work matters, but also that it is not the dominating factor in satisfaction. We can learn that communities matter and that jackasses who aren’t expelled poison the system.
The lessons go on.
If you want a place where software development is prized and made comfortable and optimized for, pick a technical system which optimizes and prizes software development, and listen, carefully, to the people who are attracted to that system.
none of the above should be construed to be compatible with the operating model of your particular enterprise. The above generally will only work in an organization which gains material benefit from materially improving software developer happiness. It might be that the corporate model is to hire cheap devs, have them crank out crap, and ship it quickly. It might be any other number of things which there’s no point in making a great dev environment.
Working with people who know what they’re doing.
That means hiring sysadmins to do the sysadmin work, not just saying “devops” like a prayer and hoping your intern can somehow secure your servers against the wild west that is the internet. Ops is a skill that takes years to hone, and you’re disrespecting the devs and the admins when you pretend they’re interchangeable. Devops was supposed to be sysadmins taking on the tools of programmers and programmers targeting the (new) platforms of admins, not a magic word that allows cutting headcount without losing capability.
It means having actual testers, not just saying “devs (or the office admin) are testers now” and praying that somehow a different hat will allow people to see bugs in code they wrote and tested to the best of their ability last week. Programmers make terrible testers, and you have no idea how happy your devs will be if you have even a single dedicated professional test engineer to work with them.
It definitely means CI, and probably CD if you’re delivering via HTTP.
It means listening to your seniors when they tell you something is broken and needs to be rijiggered, even if it’s broken in a way you can’t see. Contrary to popular belief, most programmers do not want to “gold plate” things, they just don’t want to work in the code equivalent of a workshop where there’s cables stretched across the room at waist-height, the floor is slick with grease, and there’s no shielding on the dangerous parts of the equipment.
You have misunderstood the meaning of DevOps. The term refers to bringing the developers closer to the customers (the day-to-day operations of the product/service they are building) through a set of mechanisms, including continuous delivery, which gives you quick feedback on what you are building.
It’s a very common misunderstanding that DevOps should mean “use developers for ops work” but reality is not that simple (or stupid!)
while I agree completely with the intended “real” meaning of the term, I disagree on the last point.
Reality is that stupid, and companies have and do very literally disband/defund their ops staff, on the basis that “With DevOps our devs can do Ops”.. this is often but not always combined with a Management-decided move to some combination of “cloud” computing and/or outsourcing every possible dependency to SaaS.
In my experience reality is, in fact, that simple and stupid.
Relaxed professionalism and intellectual humility. Having fun while staying in flow. Ego free.
Just from a tooling perspective, I think the ideal thing is the “pit of success”, with some escape hatches so the tools don’t constrain you when you want to do something really different.
The pit of success is: setting up CI for your new project should be trivial or automatic. Running builds not from CI should be slightly inconvenient. It probably is by default, so no need to make it bad on purpose. Now every project will tend to do the good “be on CI with a repeatable build” thing instead of the bad “be built on one dev’s workstation which is the only computer in the world which can build this project” thing. Extrapolate to everything else which we think helps or hinders productivity & quality.
The escape hatch thing is about: if it’s 2006 and you need to get on this new iPhone app store or your social website is going to become irrelevant and die, you should probably ideally be allowed to do that without having to first fight and defeat one thousand daemons that all want to punish you for daring to write something that isn’t a web app and doesn’t compile on Linux. And situations analogous to that may arise in future.
Also linters should never enforce syntax preferences. If you write a lint pass that raps someone across the knuckles for putting the wrong number of spaces between a function name and the opening parenthesis, or anything like that, I hate you. Write an autoformatter instead.
A holistic vision? I mean, wholesome is good, too.
I would suggest strong focus on interoperability (a la bezos directive..), with reasonable unilateral agreements internally on: SLA, backwards-compatibility, versioning, ownership of services/infra, multi-desking (composition of duties, not inheritance), even so far as stating preferred language/syntax/style choices. I mean, shit, I’m not trying to describe Google but I see how close I am to just saying “well just copy big G” and now can’t help but see the pattern. Makes me want to try their interview again.
Certainly not going to complain about Netflix’s pay strategy, I just wish I could write that well. Back to leetcode.. oh and put me down for large 4-cube offices with doors.
Thanks, fixed the holistic.
What do you mean by “multi-desking (composition of duties, not inheritance)”? That duties are shared between people instead of proxied around?
Instead of leaving one team for another, people should be allowed to contribute on 2 separate projects, continuously if need be, without being “owned” by one boss and “shared” to another or anything. Something like that.
All the points here so far are very good.
Fortunately, we don’t have to resort to guessing either: there’s been lots of research on this. It boils down to motivation. A motivated workforce leads to a great environment. Even better: there are concrete, proven steps to get there.
These steps are known by different names depending on who you ask, but some examples are Deming’s 14 Points for Management, lean production, and DevOps culture. What they have in common is they lead to autonomy, pride of work, security, mastery, purpose and those things that Pink brings up as components of intrinsic motivation.
Almost everything else mentioned in this discussion is a consequence of an intrinsically motivated workforce. When you have the steps in place, the rest tends to fall out of that naturally. The steps are necessary and frequently sufficient – they are what underlies all the other things people bring up.
The interesting thing is that just like with cognitive behavioural therapy, you don’t need to start out from a place of motivation to get to these steps. You can enforce these steps and this will lead to motivation!
I strongly suggest reading up on this – the world would be a better place of more people knew about it.
To put it simply, when it feels like the environment isn’t there (unobtrusive) or it’s making you more productive, rather than slowing you down
This is comes from principles of good design
Autonomy.