Ramblings about developing software
Thinking about motivation again
A while ago I already wrote about motivation and right now I am reading the book “Drive - The Surprising Truth about What Motivates Us” by Daniel H. Pink. Recently I also took part in a study by a university in Finland about motivation of open source programmers. I really think a lot about motivation I guess.
While reading “Drive” I got many thoughts and ideas on how I like to develop software. The book is about motivation and issues in established management practices. That’s why I would like to talk about how to run development teams instead of “managing” teams or projects.
I am just a humble developer who never officially managed a team or ran a company. This is just a random list of ramblings about software development I got to know over the years. So take this with a grain of salt.
This was the introduction to this post I wrote January 2022. It’s October 2023 now. I found this post in my unfinished drafts. I guess I didn’t have enough motivation to finish this back then.
Things I like and dislike
Product work vs Client work
I have spent most of my career so far on product work and less on client work, but I really prefer product work. I really like being a small part of a larger product my team can call its own. We are in charge of what gets done, how it’s done and when its delivered. Of course clients and users influence the features, design and usability by giving constant feedback, but the team has the authority. The team is also in charge of the product for a long time and can influence the vision and the roadmap. With long term investments and responsibilities on the team everyone is interested in good quality from the start and future proofing. It’s also more likely that major changes like big refactorings are undertaken because they help to work towards that vision.
Client work feels much different. You give up your authority and your task is to make the client happy. Of course you have your voice in the process, but ultimately the client has the last word because he is the one who is using and paying for the result only. Because the client and therefore the developer are mostly interested in the result the code quality and project in general can suffer from external pressure like time constraints. Making the client can be very rewarding, but I would personally think of all the shortcuts we have taken to reach the result.
Autonomy
Working on a product should give the team autonomy. Each developer should be given autonomy.
Getting in the flow
Most programmers know how it feels to be in the “flow” or “tunnel”. You are working on something with a high level of concentrations, time flies by, and you are making progress. This is usually very enjoyable and productive.
The billable hour
I don’t like documenting hours. I could never start and stop a clock to track my time working on a project. Work time is not linear for me because I can get distracted, take breaks or switch projects if I don’t make progress.
Things that could work
Software as a Service (SaaS) - Ship Features not releases
The great gift of software as a service is that you are in control of when and how users get their updates. If you are working on software that gets installed by users you need to do releases and can’t just continuously ship out your changes. You always need to worry about release schedules, when to release what and backwards compatibility. I always get the feeling that most people don’t like installing updates, and it can take a while until all of your users are using the latest versions. This forces you to make less and bigger releases which you need to test properly.
I have worked on software projects with long release cycles, and it creates extra headache. I don’t like to rush to release something or delay it for weeks or months because it’s not ready for a fixed release things. With SaaS, you can ship out features as soon as they are ready and fix issues fast if something goes wrong.
Iterate
Smart with the minimum viable feature and only add stuff after you are sure it’s good. Removing features might disappoint your users
Automate
Build automation to make releasing easy, cheap, fast and save.
Schedules
Never promise anything that’s not ready. Estimating time just doesn’t work.
Continues process development
We continuously test and ship code. We also should continuously question and improve our development practices.
Play time
Since I heard the concept of 20% projects I always loved the idea. Google allows its software engineers to use 20% of their time (one day a week) to work on projects that are not part of their main role. I like the project “Perkeep” which is software written in Go to store stuff like files, tweets, images, RSS feeds and everything you can imagine in so-called “blob storage”. The project was started by Brad Fitzpatrick as a 20% project while he was not working on Go at Google. As far as I know he used this project to learn Go and experiment with it. This lead Brad to join the Go team and Google and some stuff from Perkeep made it into the Go language.
I learned from “Drive” that the company 3M was very early to allow engineers to spend some of their time on things away from their main job. The call it “experimental doodling” and got many innovations from this like Post-it notes. The software company Atlassian started with regular one day events of hacking on new products and called it FedEx days because they wanted to deliver something overnight. The also moved to a 20% concept although the first had to convince the business people that the estimated 1 million dollars this was costing was worth it.
There are a lot of big examples like Gmail or Google News that started of as side projects and became major products. It might not be easy to implement a concept like this, but It could be worth it. I really like the idea of having 20% of my work time to spend on things like writing blog posts, writing documentation, creating new tooling, experiment with ideas for products, spend on open source projects, etc. This could be a good distraction from day to day work and make work much more productive and enjoyable.
Work Asynchronously
Getting interrupted sucks. Having to many meeting sucks. The feeling to be always available is unhealthy. Our work and communication can be done more asynchronously. Open source is a good example.
Finding the balance
“Managing” expectations
Maybe it’s just a personal thing, but I find managing my own expectations very hard, too. Especially when I work from home I often don’t feel productive. Some days I think I don’t get any work done or sometimes literally getting anything done is really hard. I feel guilty when I don’t feel productive or spend time on other things, personal stuff or even procrastinating because I don’t have the energy to start the next task that sounds very hard or is not clearly defined, yet.
Clear and reachable goals
I hate deadlines and estimating time to deliver something. It never works and is never accurate. Let’s just tell the customer the stuff we finished and ship it.
Fixed development cycles create stress.
Communication with customers
Setting expectations right: It ships when it’s done.
Endless Ticket Streams
There is so much stuff to do. I cannot try this idea now. I have to ask first if I can work on this. If this doesn’t work out the time would be wasted and could have been spent wiser.
Thoughts developers have all the time. How to escape the endless stream of work and priorities.