I watched a presentation from the KotlinConf'24 which piqued my interest. The presentation was titled, ‘The best programmer I know’ and Daniel Terhorst-North was presenting.
1) Getting the job done
Part 1 of the talk mentioned the qualities of the best programmer is “Getting the job done”
Just Start
Resist procrastination
Procrastination is difficult to handle. It is very easy to scroll on your phone,
play video games or do endless research / tutorial. It is difficult to sit down and code.
Just start is the most suitable solution, no matter how big or small of a start, just start.
Doing is research!
Know that you don’t know
Lose the ego. “I know that I do not know” is an appropriate quote for this. What you build
initially does not have to be perfect, in fact it most likely will not be perfect. You can
and will refactor.
Iterate wildly
Try, fail, learn and repeat. It really sucks to fail but this needs to be embraced. Iterate!
A fantastic engineer I know told me, “where there is a problem there’s always
a chance to learn something new”
Build a product
Invest in the outcome
Code is just the means to achieve the outcome, which is a product. Try and have no
emotional attachment to your code. It seems controversial to hold two conflicting ideas,
- Write the best code you can 2) Have no attachment to the code you write.
Study the domain
This goes without saying, but it is easy to not do this. It can be easy to fall victim
to this feature factory style of coding, where you are given a feature or story and you
develop it. Try and zoom out. Why am I writing this code? Understand the bigger picture.
Watch your users
Even if you are several step removed from your users. Try and keep them in mind.
What do they want? What frustrates them? Simplify it and eliminate it.
Solve for now
Learn to see what is really there
This is hard and takes conditioning and practice. Learn to truly see what is in front of you. What
is behind your code, break it down to its core.
Solve the real problem
Figure out what is the real problem and solve that! Dont solve some generalised or over complicated
version. It may end up reducing your dependencies.
Strive to simplicity
Simplicity is the antagonist to complexity, favour it! It is one of the cornerstones of good programming!
2) Choose the right tool
Part 2 of the talk mentions about choosing the right tool and why considering this may help you out. It is good advice so you should definitely choose the right tool…
… for the product, not the team
Teams can learn
Code outlives teams and data outlives organisations. Teams can learn new technologies and it can be beneficial for them to learn and expand their arsenal of skills.
Do the simplest thing, not the easiest
Simple is often erroneously mistaken for easy. “Easy” means “to be at hand”, “to be approachable”. “Simple” is the opposite of “complex” which means “being intertwined”, “being tied together”. Simple != easy.
The ‘right’ tool may change over time
What is deemed to be right at the time, could very well change. It is important to not stick to a tool which has become complex
to utilise, of course depending on context. There is a saying, “Make the change easy, then make the easy change.”
Make the change easy, then make the easy change
Minimise the blast radius
Build small things. Break up functionality into small pieces that communicate to each other. Small things are far simpler to maintain and
refactor in the future if required.
Reduce and reuse
This ties in with what is mentioned above, smaller things are simpler to maintain. If code is starting to get to big,
start reducing, extract duplicate code and reuse code when possible.
Then do the same with production code
Daniel came up with a set of principles for determining how good a code base is to work with. This principle is called CUPID (look it up).
CUPID is your friend. Also, architecture should not be viewed as a restriction of choice, but more like options. Architecture is
choices. Think, for each of these choices, how much will it cost for this to have been the wrong decision?
Be a polyglot
Explore languages, tools, paradims
Learn lots of different languages, they will give you different perspectives. It will give you the
experience to know what the right tool is.
Be ‘full-stack’
This is pretty self explanatory. It is a good idea to know about both of the ‘paradigms’ of
software development. Front end and backend. If you specialise in one, at least have a basic
foundational understanding of the other.
Be really full-stack
Try and think beyond just software and code. How about improving processes? ceremonies?
Challenge the status quo.
3) Caring about the team
Part 3 of the talk mentions about how it is crucial to care for the team. This can often be an over looked aspect of being a developer, but working effectively as a team can produce incredible results.
Caring about others
Find joy in helping other learn
Teaching is one of the best ways to learn! It is a hugely beneficial habit to share knowledge and teach.
It accelerates others learning while simultaneously solidifying your own knowledge.
Send the team home
No one should be working late, it leads to burnout and an up happy team. A rested team
is an effective team. A team free from implications of tight deadlines and stress is an effective team.
Be kind
Assume everyone is doing there best. Build psychological safety for the team. This is what it means
to be a team lead.
Caring about staying current
Join communities
Join communities, get involved. Staying current and collaborating with people with different
tech skills and background will be beneficial. Be a contributor to certain communities.
Try new things
As established earlier, try new things! Try new technologies but remain a healthy skepticism. This
is exactly how you can build up your skills.
Practice practice practice!
There is no substitute for practice. Understand that there is no ‘innate’ programming gift. Just a
lot of curiosity and passion to try new things. Be prepared to be rubbish at new things.
Caring about yourself
Have interests and hobbies outside of programming
There is nothing quite like being active and having hobbies outside of your main focus. You are sitting at
a desk all day, be active and stay healthy.
Go home on time
Sleep is the best debugger. Who will remember you working late? Make yourself a priority always.
Be kind to yourself
Always be kind to yourself, every day is a learning experience. If you were stuck on something
that ended up being simple, don’t beat yourself up for it. Learn from it and grow.