
Improving my productivity as a working programmer (2017) - dailymorn
https://malisper.me/how-to-improve-your-productivity-as-a-working-programmer/
======
pritovido
In my experience as a programmer:

1.Learn deeply about the psychological mechanism of procrastination, pay good
professionals if needed. Any any skill, it takes years to master, but pays
off.

1\. Do not stop reading HN, just use it as a price, when you complete a
difficult task. This is very important, people will usually use HN of whatever
as an excuse for procrastination, because it is easier to read (be passive)
than create.

It has been extremely useful reading HN over the years, I spend over 20
minutes every day. I do not go deep but use Zotero to store anything
interesting. When I need this for my work I just go to zotero and study deeply
for days this useful info.

2\. Learn how to make the machine program for you. Learn lisp, learn
functional programming, learn lisp macros and metaprogramming. Learn grammar
systems and how to create your domain specific languages.

Even if you don't use functional programming or lisp, the concepts and ideas
you get from understanding it makes you avoid making bugs, or you know how to
automate everything, including finding bugs.

This also takes years to master, but your computer can write hundreds of
thousands of lines per second. Most people only write 20 or so per day on
average.

3\. Learn how to manage other people so they do the work for you. Learning
psychology will also pay it back here. If you master psychology, people will
be able to do things under your management that they are not able to do on
their own.

~~~
FreezerburnV
What do you mean when you’re talking about learning deeply about the
psychological mechanisms of procrastination? Do you have any links to start
with that? It’s something I’ve struggled with my entire life, and if there’s
something I can do to learn more about it and be able to overcome it over time
I’d love that.

~~~
hoorayimhelping
CBT (Cognitive Behavioral Therapy) helps tremendously because the whole
schtick of CBT:

1\. become aware of a feeling happening (in this case procrastination). By
becoming aware of it happening, you can consciously overcome it ("hey I've
been looking at HN for 35 minutes, I should get back to work")

2\. start understanding the conditions which exist which cause this emotion to
happen ("I notice I always procrastinate when it comes time to update my
react-redux actions and reducers. It takes so long and is so tedious, I'd
rather watch a youtube video")

3\. start working on the conditions which cause you to procrastinate - start
to understand what it is about modifying react-redux that sucks. Is it
inherent and something you're just going to have to grind through? Is there a
process you can change to make the work easier?

Those three bullet points are a very high level overview of something a
therapist or coach will work with you for months on. But that is the general
flow: identify a feeling -> identify the root cause of the feeling -> change
the root cause, or become aware of and okay with the feeling happening

------
afarrell
> Eliminating Distractions

One challenge is that there are some things which _should_ distract us:

1\. Pull Requests which we should review to unblock our teammates.

2\. Production errors which should be investigated.

3\. Slack messages from those 1-3 people we are immediately working with and
which they'd want to interrupt us with.

4\. Fire alarms which are not weekly tests.

5\. Messages from spouse which they intend to inturrupt us with.

For me, one big win has come when I was able to put a Zeroable Inbox of PRs-
to-review on my menubar. Instead of searching through github, I could just
glance.

~~~
slumdev
A pull request should not be blocking.

They shouldn't sit unreviewed for days, sure, but addressing them within a few
hours should be sufficient. If your colleague can't get anything done during
those few hours, you might not be decomposing work to a small enough
granularity, or there could be problems with your application architecture.

~~~
shawnz
I think it can safely be assumed that there are problems with any large
enterprise application architecture.

------
collyw
Fuck it, the entire work environment seems designed to decrease productivity
(open plan offices, meetings scattered thought the day, constant changing of
task priorities, half arsed documentation of our product).

Why should I bother about making myself more productive when so many factor
outside of my control are doing the opposite?

~~~
slumdev
You might be happier. If everything runs on pointless meetings, ServiceNow,
and Jira, then learning how to best use your time in between those things
would give you more control over your time (even without getting you away from
those things).

~~~
collyw
I meditate and try not to let work affect me in a negative way any more. I
still try and make an effort to do the best job I can in the time given, but
it seems pointless trying to optimize specifically for productivity when so
many factors going against it. I have also come to the conclusion that being a
decent team player and other non-coding skills are probably valued by
management as much as coding productivity.

------
edhelas
What if I don't want to improve my productivity ? Just take time. After
working for years on some projects I know that I'm writing the more efficient
and concise code after days of "doing something else". Several days of
thinking for only a few hours of coding in the end.

I've solved concurrency issues I had for weeks by walking for several hours in
the forest. Code should not be about productivity. Life should not be about
productivity.

This article seems to be written from someone that is addicted to work. Why
should we force ourselves to organize our days to improve our coding time ? We
should organize our life to improve our reading, playing, resting time. Life
is about surprises, unplanned things, meeting new people and breaking some
habits.

~~~
thquad
Improve productivity so that we achieve more in less time so that we have more
time for leisure on a daily basis.

~~~
CaptArmchair
Parkinson's law says: "work expands so as to fill the time available for its
completion"

[https://en.wikipedia.org/wiki/Parkinson%27s_law](https://en.wikipedia.org/wiki/Parkinson%27s_law)

Completing tickets, issues or burning story points means next to nothing if
the work you do is detached from reality. And that reality consists of an
irrational humans with complex, contradicting demands and needs and an
unpredictable future.

Moreover, if you work as an employee, you will spend 40-50 hours a week at the
office regardless of how fast or slow you're grinding through the workload.
Why? Because that's how salaried work is legally organized.

Then there's limited agency. The article assumes that programmers are free to
arrange their schedule. But that's only true if you're an independent
contractor who's not deeply embedded in a team. Most programmers - and workers
in general - are subjugated to the authority of managers and specific
workplace culture.

Trying to rally workers around the battle cry "let's improve productivity"
without questioning to what end, well, that's just a bad take on Taylorism.

~~~
edhelas
^ This

------
vnorilo
I think "amount of work done" is a problematic metric. True greatness in
programming is architecture that makes problems and edge cases disappear and
nips the proliferation of complexity at the bud.

The machine and the human both do _less_ work.

~~~
pingyong
While I completely agree with that in general, the opportunity for practicing
it is unfortunately seldom a reality. I mean you need to be in a situation
where

\- You're designing a new product, or relatively large / independent new
feature of a product.

\- You also have a decent amount of time to think about it, maybe experiment
with some performance characteristics, and not be under pressure from
"management" (or whoever else) to have a "working" demo version quickly so
they can actually show and sell it to people.

Sure it happens sometimes, and it's great, but I would argue for most
programmers this isn't their daily reality.

------
multiplegeorges
> Now that I’m aware that I spent so much time isolating which function a bugs
> are in, I now test each function as I write it to make sure they work.

He empirically discovered test-driven development!

~~~
TeMPOraL
and/or a proper use of a REPL, and/or to compile and run frequently.

~~~
malisper
You're telling that to someone who has Lisp in their username :)

There's still a difference between testing while writing it and after writing
it that's independent of whether you have a REPL or not.

~~~
TeMPOraL
:).

I do both, but I find the former significantly easier when you have a REPL vs.
having to write little test programs on the side.

------
ivanhoe
These are all valid points, but IMHO these fall under fine-tuning for max.
performance when you're already fairly efficient. For us struggling with
basics one thing that helped me a lot was to shift the focus from micro-
optimization of "how I work", to focusing on the rest of my time first. Not
letting myself to drift away from work for too long (like now reading HN),
trying to cut on time-wasters so that I still can have enough
sleep/exercise/free time, having realistic goals for the amount of work I
take, etc. Putting that side of equation under control can then significantly
simplify optimizing the work performance.

------
phodge
> I realized I was spending about a quarter of the total time implementing the
> feature tracking down which functions the bugs were in!

This was a huge problem for me back when I was doing web development and had
to support IE6. I write hundreds of lines of code which worked fine in
Firefox, but then it would crash in IE with no descriptive error message and I
would spend an eternity gradually commenting out more and more of my changes
until I found the offending line through a tedious manual brute force
bisect/test process. I was able to increase my productivity by testing every
individual little change in IE as I made it, so that when I got some vague
error, at least I knew there were only 10 lines of code where it could
possibly be originating from.

However, these days with all the linters, typecheckers, and good error
tracebacks in browsers, I'm much faster if I leave all my testing for the end.
In fact, I've spent the last 2 weeks refactoring one of my side projects and
only bothered testing right at the end. There was only a handful of simple
bugs that TypeScript and Mypy couldn't detect, and the in-browser errors told
me exactly where to look to fix them.

------
decebalus1
Alright. What are we optimizing for? Productivity? Or the end-goals of any of:
achieving more, climbing the corporate ladder, making more money, etc..?

As years go by, I realize more and more that productivity is only a small part
of the equation. Even more, it's a 'metric' that if increased past a certain
threshold, it actually provides diminished returns in the grand scheme of
things (basically working more for less results).

What I found to be the perfect (for me) solution is to maintain a stable and
consistent productivity but be really REALLY picky about what I'm working on.
Trying to improve my productivity was something I was doing in my early 20s
and It's often a trap as it's conditioning your mind to be brave about taking
on more work. Nowadays, that's something I actively avoid so that I focus all
of my energy on stuff that actually matters. Thorough the years this has
proved to be a way better way for me to be successful in the work environments
I've passed through...

------
xez
I have actually used that technique of watching myself perform a task when
trying to improve my workflow for other things, like learning to draw and
paint.

I never applied it to programming before but in hindsight it's really obvious,
because it's incredibly effective. I use a tool [0] to record a timelapse of
the desktop, because after a while watching the recordings in real time slows
me down more than it helps. I find that usually when I focus on the task at
hand I tend to lose track of time and of what I'm doing and when I get stuck I
end up wasting a ton of time doing trial & error instead of taking a break to
think things through properly, or switching to something else. This kind of
stuff really adds up in the long term.

[0] [https://www.lomakescomics.com/cafe/](https://www.lomakescomics.com/cafe/)

------
jackkinsella
I found your idea of recording the screen during work very clever and I plan
to replicate.

Some things that have worked for me:

— learning to type programming symbols accurately and with confidence. I
realized when pair-programming that I lose a ton of time to backtracking due
to typos. This is particularly bad when working in interactive code consoles
where the poor editing capabilities mean typos are more costly. There are web
applications out there like typing.io that help with this.

— keeping a "dumb mistake log" where I write up any silly errors that cost me
too much time so I'll know to double check these things next time (e.g. "space
instead of tab in Makefile > make tabs appear differently", "wrong file but
with same name > keep an eye on the folder in the editor when switching
files")

~~~
Cthulhu_
In addition to the "dumb mistake log", see if these things can be automated;
for your Markdown example, set up your editor to format / fix issues
automatically, e.g. using Markdownlint. Use the available tooling; take some
time to tweak your editor, that kinda thing.

------
cranekam
> To eliminate that problem, I put my phone far away from my bed at night.

My wife and I recently started leaving our phones in another room overnight.
It's a big improvement -- previously it was easy to mindlessly scroll through
nonsense before sleep and again in the morning when waking up. Now we read and
talk more. It's still easy to grab the phone and go back to bed in the morning
but overall it has been a very positive change.

~~~
clarry
I'm so glad I never picked up this habit.. my phone tends to last at least 5
days on a charge, with a few minutes of screen on time.

Still procrastinating too much on HN & IRC with a PC.

HN is a blessing and a curse. I've learnt a lot here, but there's also a ton
of (attractive) noise.

~~~
celticmusic
I'll often just forget my phone in my home office, sometimes for an entire
weekend. I've had people ask me if I was unhappy with them because they called
and I didn't get back with them immediately.

I know it makes me an old fucker, but I'm genuinely sad when I go someplace
where we have to wait and it's just a sea of people on their phone with little
to no interaction amongst themselves.

~~~
cranekam
Tell me about it. I'm trying to reduce the amount of time I spend on the thing
(I turn off as many notification as possible, put timesucking apps out of easy
reach, etc) but it still consumes much more time than I'd like. I despair when
I see a crowd of people silently exercising their scrolling thumbs in complete
ignorance of each other.

------
luord
> Instead by aligning all of my meetings right next to each other, I go
> straight from one to the next. This way I have fewer larger blocks of time
> where I can get into flow and stay in flow.

I would probably go insane, depending on the team. When being polite is
paramount but your teammates are deeply, deeply incompetent, there's only so
much one can take at once.

Nevertheless, this is solid advice.

------
Tomminn
Whenever I see a productivity blog by someone who is enthusiastic about recent
changes they've made to their life, I immediately assume the writer is quite
young.

As people get older, they realize that you only have the "right" to write a
blog on productivity if you've actually found a system that keeps you
productive for years on end.

If you do find such a system, it's much more likely to be idiosyncratic,
involve a complex set of barely conscious reflections and automatic
associations which get you into a certain frame of mind, and also almost
impossible to fully describe since you probably don't understand every element
of it. Which makes it nearly impossible to write about.

By this I mean productivity becomes part of who you are, so that your
"productivity system" becomes barely distinguishable from your personality.
That is, to outsiders, you have a productive personality, or you are "just an
innately productive person".

This alienates the productivity seeker, because not many people who are not
productive currently can imagine becoming innately productive people. So in
turn they seek help from people who are not "innately productive", and instead
have recently developed some kind of conscious system to deal with
productivity. Which is a fragile approach.

The blockage points seem to be identity trade-offs like "are you willing to
become less open-minded and curious to become more productive?". Because often
what is holding you back is an addiction to a certain frame of mind that is
antithetical to completing a specific set of tasks each day. The blockage is
that you're not actually willing to become an innately productive person.

~~~
rguzman
> Whenever I see a productivity blog by someone who is enthusiastic about
> recent changes they've made to their life, I immediately assume the writer
> is quite young. > As people get older, they realize that you only have the
> "right" to write a blog on productivity if you've actually found a system
> that keeps you productive for years on end.

i broadly agree with you -- i'm not sure it has to do with the author's age,
per se, but productivity advice based on recent changes to the author's
systems ought to be taken with a huge grain of salt.

that said, i do think it is good to share what one is trying and whatnot --
blogging is cheap. for example, while the reader-beware above applies to this
post and most of the ideas were familiar to me, i had never thought to record
my screen while i code to get feedback, despite the fact that i record myself
regularly to asses performance in music! that bit alone made it worth the 5
min it took to read.

~~~
ChrisMarshallNY
I'd suggest that blogging ( _good_ blogging, anyway) is not exactly cheap. It
can take a day or two for me to write one of my articles.

I will do this in order to take a break from my coding "head."

------
thecleaner
For me the biggest productivity boost was using pomodoro method with coding
being done in 30min bursts. It helped reduce mental tiredness and thus bugs.
It would actually be great to hear perspectives from people who have used this
technique for an extended duration of time.

------
angarg12
> I now schedule meetings specifically at the times of the day when I’m least
> productive. It doesn’t take a ton of energy to sit through a meeting

I'd say that if you can just sit through a meeting and do nothing, you should
really consider if you should be there at all.

I recently moved to a new team and we are having tons of meetings to discuss
design, architecture, or the general strategic direction of the team. Some of
these meetings involve a lot of discussion, brainstorming and presenting your
ideas, and they drain my energy. But I found that the more exhausting the
meetings, the more useful they are.

~~~
malisper
Sit through a meeting is a bit dismissive. Most of the meeting I had at the
time were 1 on 1 meetings. They were more about sharing context with each
other and discussing current problems on the team than figuring out complex
problems.

------
adamzapasnik
That kind of advices and processes are cool and working when you are working
alone. When you start working in a team, a lot of times you depend on
someone's else outcome, so in the end you are waiting until they are done, and
there goes your productivity.

I'm not even gonna mention times when team isn't using formatters, CI is
broken and so on, and you can't fix all of that, because it's more important
to deliver a feature A or just a team leader doesn't see a value in that
changes.

So remember, developer's productivity != team's productivity.

------
andai
The "watch myself code" bit is genius. I used to do that and found it
extremely helpful -- way more helpful than apps that just show you what
percentage of your time you were in the text editor.

On Windows I used TimeSnapper Classic (free) and later used ffmpeg to convert
the GBs of images to videos. Does anyone know a good way to do this on linux?

Making a new file per screenshot wastes tons of space, I think I might as well
use ffmpeg for recording a screen vid directly at a low framerate (and maybe
somehow add a time display?)

~~~
MichaelMoser123
it helped me to understand that the tools that i was using sucked. I used to
work with vim without asynchronous builds. Once upon a time that was good
enough, but then they started to use dockerized builds that take ages. Now
With asynchronous builds I am no longer blocked waiting for it to compile/link
whatever.

as a result i brushed up my vim scripts and put them here:
[https://github.com/MoserMichael/myenv/blob/master/VIMENV.md](https://github.com/MoserMichael/myenv/blob/master/VIMENV.md)

------
wakatime
While building this developer dashboard[0], improving productivity has been
one of the main goals. However at the individual level, it still comes down to
eliminating distractions, prioritization, and other things outside the scope
of a dashboard. This article gets individual productivity right, which is
high-touch and specific to each person.

[0] [https://wakatime.com/](https://wakatime.com/)

------
neonate
[https://web.archive.org/web/20171112114756/https://malisper....](https://web.archive.org/web/20171112114756/https://malisper.me/how-
to-improve-your-productivity-as-a-working-programmer/)

[https://archive.md/nq3wD](https://archive.md/nq3wD)

------
RickJWagner
I think there's some really, really good advice there.

Probably the one that would pay off most (for me, at least) would be to 'watch
myself'. I bet I could find some areas for improvement. Then again, having the
discipline to change based on that knowledge is another thing.

I'm glad I read it. Kudos to the author.

------
cryptica
>> For the past few weeks, I’ve been obsessed with improving my productivity.

I was skeptical about the article from this first sentence. Productive people
hardly ever think about productivity and especially don't have much interest
in writing articles about it. This is because productive people (in the sense
of value-production; not value-capturing) are not focused on optimizing
processes, instead they're focused on following the shortest possible path to
reach their goal; processes are not needed; they evolve naturally to fit a
purpose and don't need to be 'designed' explicitly.

If you're a founder or CEO, then you do need to think about processes, because
you're not a value producer, you're a value capturer. Processes are your bread
and butter; they're a tool to keep you in your position; so thinking about
productivity and preaching about it is the shortest path for you to maintain
control and increase your influence.

They should make a new word, "captitivity" to differentiate productivity in
the sense of creating value efficiently versus productivity in the sense of
capturing money efficiently.

~~~
phodge
I'm not convinced. Often the productive "hard worker" persona tends to push
through tedious manual tasks, where the unproductive "lazy" persona gets bored
and looks for better ways to do things.

~~~
cryptica
The lazy persona risks not understanding the problem well enough to come up
with useful solutions.

You need repeated exposure to the problem in order to see patterns and to find
a good solution. I agree that it's good to take a step back from time to time
but IMO it doesn't make sense to think about productivity in a generic way
(e.g. in terms of time management). Even the author admits that "getting in
the flow" is important. The flow is everything. My point is that you should
make your entire life about "the flow".

------
osaatcioglu
"Watching Myself Code" is a simple but incredibly good method to have self-
retro sessions for self-improvements.

It might be hard to find the exact time to observe, though. Commit history
could be an indicator.

I will definitely try that. Any recommendation for a screen recording tool on
Mac?

~~~
LeonB
I co-wrote a tool called TimeSnapper that has helped me perform “self-retros”
exactly as described in this article.

It’s on Mac now as well, though not free.

~~~
keyle
I was going to give it a shot but I must say the price is a little out of my
range for this type of tool. Am now considering the opportunity to write my
own (for myself)... I guess I'm looking for a side project...

~~~
LeonB
I’ve sent you an email.

------
block_dagger
How about improving wisdom? Following the guidance in the article, despite its
best efforts, will lead to lots of code. Code that will be replaced by a wiser
coder in less time.

~~~
malisper
> Following the guidance in the article, despite its best efforts, will lead
> to lots of code.

I don't think that's necessary the case. My goal in being productive is to
produce the biggest wins in the least amount of time possible. In many cases
you do that by coming up with a better design and writing less code to begin
with.

In fact, I wrote another post[0] on how I approach becoming a better
programmer. The two key principles I use are learning how to solve existing
problems faster and learning to solve new problems.

[0] [https://malisper.me/my-approach-to-getting-dramatically-
bett...](https://malisper.me/my-approach-to-getting-dramatically-better-as-a-
programmer/)

------
jefurii
I do all my personal browsing in Firefox and my work in Chromium. When I need
to concentrate I run `pkill firefox`.

------
commandlinefan
> Eliminate distractions

difficult to do when every organization in the world makes a point of
introducing as many as possible.

------
scoutt
These are interesting tips. Personally I believe that 7 hours of good sleep
supersedes all other tricks.

------
rgg_32
I think a lot of people here aren’t seeing the high picture.

Becoming more productive at this level makes the programmer environment
significantly tougher and it has negative consequences over time to every
human being. It’s a fact that many people don’t even think about it. If you
optimize yourself to near –let’s say 95% of your actual capability, you are
making everyone else optimize themselves to this number over time. This is
great on the context of capitalism and economic growth, you produce more in
less time, but we are forgetting that we are humans, not machines being
optimized. Of course it’s okay to strive in this life to progress and achieve
certain goals, but as happens in almost everything in this world, there should
be some limits. If you are getting to the point where you have to monitor
yourself, schedule every part of the day and establish X number of controls on
yourself, you are being a company, not a human being, and you really aren’t
understanding the point of life.

This is a common trend I’ve been realizing for years, we have been sold the
idea that we should improve more and more and be more competitive, but without
any limits, this is going to negatively affect our lives, indeed, it’s
happening right now.

------
thrower123
When you become too productive, you wind up doing all the work you need to do
between 9 and 10 am. Then it becomes a question of whether you generate extra
work, or if you generate the appearance of doing work.

I'm increasingly of the opinion that appearing to be busy is less dangerous.

------
the_dripper
thank you for publishing this :)

------
akullpp
Why do software engineers tend to see themselves as machines with the
necessity to be optimized for productivity or is this solely the cultural
influence of American capitalism?

While I agree that it is a good idea to optimize chores, so you can focus on
interesting issues, I often hit a wall of processes or humans.

One consequence, after a decade of professional work, is to actively dismiss
the idea to optimize every part of my life. On the contrary, I value the time
where I do nothing at all. It often allows me to clear my mind to be more
creative afterwards.

So what I'm really missing, from this very basic article that does not provide
any new information, is: Take your time off and do nothing.

~~~
kubanczyk
> Why do software engineers tend to see themselves as machines with the
> necessity to be optimized for productivity

The good'ol case of "if the only tool you have is a hammer, every problem
looks like a nail".

I'd paraphrase to: if you spend half of life optimizing machines for
productivity, every problem looks like optimizing a machine for productivity.

You are wise to consciously avoid it. A little bit of discipline goes a long
way.

~~~
TeMPOraL
Huh. I'd go the other way around: if you've found a game-breaking ultimate
superpower, of course you're going to use it.

Ability to reason about and optimize systems isn't "the only tool" a conscious
programmer has, it's an _additional_ tool they have that _most of the
population don 't_. So perhaps "software engineers tend to see themselves as
machines" that _can_ be optimized, because they _can_ see it where others
can't.

~~~
kubanczyk
That old saying suggests: be humble. Ultimately we are lazy about how many
different worldviews/perspectives we actually use. As compared to how many we
_think_ we can use.

Don't think that since you found a good tool, you are a unilateral master of
it. Using the tool, any tool, is bilateral relation.

------
gombosg
It's a nice article, but the title says, how to improve _your_ productivity -
and the article contains a whopping 120 occurrences, of "me, my(self) and I".
It's really hard to read it and relate to it that way because it sounds like
the bragging of an egocentric person instead of useful, actionable advice.

~~~
cranium
I would disagree with you: the headings are the actionable advice. To
paraphrase:

    
    
      - Eliminate distractions
      - Facilitate yourself getting in the flow
      - Optimize your schedule around your productivity peak
      - Record your screen to do a retrospect and see where you waste time
      - Daily and weekly retrospect
      - Don't implement too much at the same time
    

The paragraphs below are just the author personal implementations, which will
be egocentric by design.

~~~
slotwa
How did you find your productivity peak? By recording screen? I'm struggling
to get to know when my peak is (and I'm a little afraid that I don't even have
a peak at all)

