2024.06.25 Tue 19:56 Perfection on first try

Why all this effort writing automated tests for software, maintaining
staging environment, logs, rollbacks and status monitoring?  Just make
a decision to write code right on the first try.  Then you can work
directly on production environment without any tests.  Brilliant!

That was our running joke at work few years ago.  Obviously everyone
would like to write perfect and bug free code every time, to have less
trouble later, maybe promotion or better product giving higher sales.
However it seems impossible to have flawless solutions even after many
iterations when working on big project.  Anyway, who cares?  Usually
the larger the company, the less people care about quality.  Making
beautifully engineered solutions is out of question when working in
Agile [1].  It seems like nobody cares about perfection at work.  Well,
I do for selfish reasons, here is why and how.

What I want is to write code my way at work.  The definition of "my way"
is different for everyone.  To me it means to have better quality with
less code, simpler solutions with no clever ideas, robust system that is
easy to understand with repeating patterns, less dependencies, no happy
paths without handling every single error, straightforward architecture
and no OOP madness.  There are few obstacles to overcome in order to
gain control.  Obviously there are other programmers with different
opinions, there are company guidelines, legacy code, architecture etc.
At every single job I had, working in team with other developers, it
becomes apparent that to have program written your way you just have to
write most of the code yourself.  You can for example rewrite a lot of
legacy code as part of some tasks, or write majority of the code for new
functionality, or influence other [2] and the best way to do so is be
example.  People will recognize patterns of your code and they will
happily repeat them if they like them, or if they see that most of the
code is just written that way.

So what I need is to write significantly more code than others.  The
obvious solution to that might be to work faster.  But I disagree.
Going super fast is pointless if you are on the wrong path.  It's much
better to know where to go than go fast in wrong or random direction.
I discovered this by watching streams of experienced programmers.  They
usually write code very slow and use only basic text editor capabilities
without any IDE features.  Even in case of someone like Casey Muratori
[3] who writes code faster than you ever will, he spends most of the
time explaining code than writing it.  Despite the apparent slowness
their achieve great results in short time.  It's possible only because
code is written right on the first try or with very few mistakes.  This
ability is gained with experience.

There are other things that can be done to write more code than others.
And by more code I mean code that is useful, not the Object Oriented
boilerplate or some template.  You can always work on the speed of your
work but there is only some much time during the day.  At some point
improvements in automation, tools or workflows will give little to no
gains.  IMHO the biggest potential is hidden in your ability to focus
and capacity to pay attention.  I wrote about this before.  But this is
not a secret knowledge.  Everyone working at office knows that one hour
of honest work produce more results than whole day of unfocused work.
The difference when working with full concentration is huge.  Imagine
what you can do if you could maintain full focus for whole day.  It is
common to believe that such concentration requires a lot of energy and
it will destroy your health in the long run.  This is just another
excuse for laziness.  What drains your energy is everything else that
demands your attention that is not related to your work.

The problem here is that employees are set for failure.  Distractions
are baked into office work and we are encouraged to have more of them.
But this can work for you.  Because I have selfish goal of writing more
code than others it's possible to exploit this behavior to my advantage.
OFC I'm doing it only on my side.  I'm not trying to make anyone else
less productive.  That would be easy tho.  Anyway... the goal is to have
full concentration for most of the workday.  The more hours the better.
Remove distractions, be radical and honest with yourself.  Here is how
I see it:

- No phone, music an notifications.
- No task switching, no stress, be assertive.
- One break, no snacks, just a glass of water in your reach during work.
- Work during less active days and hours, early hours and holidays.
  During hours of most activity your will have a chance to work on your
  assertiveness and company wide meetings are your greatest trial.

I'm deliberately avoid writing about improving your tools and workflow.
This is huge topic that OFC makes a big difference.  Your ability to
resolve problems with tools you know can often make a difference between
success and failure.  Many times I saw an programmers that can only use
an IDE and search for answers on internet.  They are helpless when those
tools fail to deliver.  And you know that you work on serious problem
when commonly used modern tools are useless.  Best time to shine.

Knowing the direction of your work, having concentration, skill with
tools is just the good foundation.  Strategy is what will give you
results.  Most of developers don't have such goals so you can easily
steer the events any way you want without anyone knowing that you are
doing something.  And to be hones, this is also beneficial to the
development team and company.  Because strategy is just another way of
being concentrated, but with the bigger picture in mind.  Few options:

- Be the guy that dives into legacy code that no one want to work on.
  That way the legacy code will become your domain and you will be able
  to do with it whatever you want.
- Work on system critical functionalities.  Those are often maintained
  only be one or few people.  The less eyes on the code you work on the
  easier it is to make it the way you like.
- Work on difficult bugs.  People have no patience to dive into do the
  hard stuff.  Complicated bugs are a great excuse to refactor a lot of
  code and work on something longer without distractions.  In the end
  everyone will be happy that problem was solved.
- Become a team leader.  That way it's easier to distribute tasks the
  way you want.  With that you can apply the same strategy of writing
  the code "your way" to others.  They will become experts in specific
  domain if you always give them specific tasks.  They will be very
  familiar with code there as most of it will be written by them.

What not to do:

- Work on new features.  Those are often created in big hurry and all
  developers love to write new code.  If you have big project then it's
  much better to make old code the way you want.
- Work on simple bugs.  In those you will spend more time testing and
  managing Jira, GitHub and other tools than programming.
- Conveyancing others to some rules by form of meetings.  You will only
  meet with resistance if you try to change something openly.  It's
  much better to avoid attention and work behind the curtains.

Yes, I'm willing to strategize just to have more functionalities created
the way I think is right.  All of this is very egoistic but I believe it
to bring great benefits to development team and whole company.  Agile
has this idealistic idea that everyone should work on everything.  Such
idea sells great but works poorly.  The opposite is true.  If you have
one expert in specific domain that knows ins and outs of particular part
of application code then the most unexpected will happen.  That person
will care about the quality, will understand the code base, will like to
spend extra hours on refactor, will fell responsible for it and then ...
eventually will write new code right on the first try.

And this is the final goal.  When you are focused, have great tools, you
understand the domain and have code written the way you like, then you
have a chance at writing the code right on first try.  You can't go
faster than that.

I can already hear the voices saying that such employees are hard to
replace, there will be no documentation [4] written etc.  To that I can
only say that I prefer to work with employees that feel ownership over
what they work on than employees that care less about the work.

Post written NOT perfectly on first try.

[1] https://en.wikipedia.org/wiki/Agile_software_development
[2] "And the greatest of victories are not manipulations at all, but
    simply awakening others, to the truth of what you believe" - Kreia
[3] https://xcancel.com/cmuratori
[4] http://arek.gabr.pl/docs-by-code-and-comments.html

EOF