a_better_stick.htm
You don't need a better stick
It can be easy to fall in love with computing because of the possibilities powerful tools can give us. They can become a bicycle of the mind as Steve Jobs would say.
When I joined a start-up after graduate school, I had a drive to adopt new tools and change things. We had what I perceived antiquated tools. Not the best tools we could get for the job.
From a new engineer's perspective, it made sense. If you want to do a good job, you search for the best software you can find. If you have a great tool, you won't have any faults in your system.
It can be an ego boost to put your fingerprint on new solutions. You know that what you added to the systems had a direct impact. Especially when systems are failing, it can be tempting to replace every tool and think it will improve overnight.
As I kept trying to propose new tools, new HR systems, new databases, new orchestrating systems for data. I realized I faced increasing resistance.
It taught me a few things about changing systems in production.
I. It's hard to change tools in established companies
- Why humans have a hard time with change in general
- There can be a strategy to not implement new tools e.g., Stripe's strategy to keep using Ruby
- What an engineer sees as priorities
- What business people see
- How you need to find the overlap and make your case for it
- You are always negotiating in companies
- How to get past no
- How to see things from the other person's perspective
II. New tools are not necessarily the answer
- Do new things with old tools, or new things with old tools
- You need to train people with the new tools
- Many smaller companies just rely on the knowledge of the first joiners
III. If systems are failing, its important to look first at processes
- Stick story
- Process developer survey deep dive
- What are the most important processes to test production systems
Once Once I started proposing new tools, I realized, in my naivety. That in established companies, you can't just go in and try to change things.
If there's a fence in the middle of nowhere there might be a reason for it.
[Add picture of fence]
There's an established order of things. Changing tools takes time. And many companies can't justify spending the time on it. That is one of the reasons why Stripe famously decided to stick with Ruby as part of their tech stack [add content].
[Needs connective tissue]
I also changed my mind, when at work, I had one infrastructure manager tell me a story of a man in India who wanted to cook roti like his grandmother.
He tried and tried, but failed. He thought if he had a better stick, longer, made out of hard wood. Maybe then he could make roti like her.
After getting the stick he wished. He spent hours making the roti and took it to her. When she had her first bite she grabbed the broken, crooked stick she used for over 40 years and smacked him in the head.
You don't need a better stick, you need learn how to use it. If you don't know how to use the stick you will keep blaming it for your own faults.
After she told me the story, it didn't really sink in. I was too proud to give away to something so basic as a process for the fault in our systems.
< Why you should do new things with boring tools or old things with new tools >
< Why processes with those old things can actually define and improve the developer experience at your company >
https://newsletter.getdx.com/p/software-quality
Storyline
Tools can be great
As a new engineers you love using new tools and learning new things
Its also great feeling your impact, your ego fill up, as you try to change things at your company
Especially when things are failing, you think a new tool will fix everything
Hard to change things at companies
- Why is there friction to implement new tools
- What are the other aspects you don't see as an engineer when implementing new tools
- What are things the business sees but you don't
Why newer tools are not always the answer
I kept trying to change things and faced resistance; until one director told me, getting new tools won't solve your problems; don't blame the stick if you don't know how to make roti
I started realizing that maybe new tools aren't the full solution
- famously some people argue you should do new things with old tools
I also started learning about developer productivity
- What if process was the key; not tools or gadgets
- Introduce google developer experience survey
Process is at the heart of failures; fix processes and you will have better outcomes
How to fix processes? Use systems thinking, what's the bottleneck, what are the inputs, outputs, failure points, etc...
Think process before think changing things