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.
Re 2: I love the idea of automating, but it rarely seems to pay off, because you really need a large number of users for it to be worth the effort to finish it/polish it properly - ease of use, ease of deployment, docs, helpful error messages, samples etc. All the things Fred Brooks talks about for a "programming product". https://wikipedia.org/wiki/The_Mythical_Man-Month
That's why we have products (including open source tools).
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.
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
I struggle w this too. No good links to share but IME it's primarily emotional not logical. It helps if you can find some spark of enthusiasm for a specific tiny single step, because having started makes it possible to get into flowstate and/or discover other potential hooks or (re)entry points for the next time.
If genuinely "stuck", try stepping away from it, going for a walk, and considering the simplest thing that could possibly work; ok to start there and refactor later.
Making plans? Think big. Making progress? Think small.
Also, standard self-care stuff (sleep, exercise, meditation) is critical.
Yes, writing tests work when you already identified the potential bug if future code changes break things. My first thought was you can't automate bad logic bug discovery.
But you almost can. There are tools like mutagen[0] that compile modified versions of your source mode, and if all your tests pass, then your tests don't actually test the logic that was changed. Now there's a lot of nuance to it (false positives, don't run this on stuff that can write files, etc.), but the basic concept is another good step towards automated bug detection.
There's also fuzzing, but that's (IIUC) not so much about bad logic but instead about finding novel (usually bad, memory driven) states.
> 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.
I hope you're referring to cases where you're a project lead or in a position of management. Because if not, tread with care as most people can be easily influenced but if you run into another person who 'masters psychology' you may end up having a really bad time.
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.
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.
> One challenge is that there are some things which should distract us:
> 1. Pull Requests which we should review to unblock our teammates.
For PRs, it's unlikely that the person making the PR needs you to review it right this second. It's ok if you finish what you are working on now while you are still in flow and after an hour or so, review the PR.
If your teammate has nothing to do during that time, that's a completely different problem.
I don't agree, except for the fire alarm of course. Almost nothing is so important that it needs my attention immediately. I will manually check for new notifications about every hour and never got complains for being unresponsive. As a side effect, I stopped ghosting people unintentionally by forgetting to respond later.
I've learned to get any deep focus, I need to eliminate emails and Slack for this time (including things by the closest collaborators, directly on the project, life partners, anyone).
There are exceptions and emergencies (then, and only then - unscheduled phone calls), but only in case when it is worth canceling all daily progress.
I think it is reasonable to expect pull requests to be reviewed within 24 hours but not necessarily sooner. From this it follows that one can pick a convenient time for them every day and for maximum efficiency one should do precisely that.
Re: 1, pull requests should not be blocking; if it is blocking, go for pair programming instead and/or in addition to. If a pull request not being merged blocks someone else then you need to review your planning.
2. Yes, but it should interrupt the whole team. Share the pain, the cause, the solution, and work on how to prevent it in the future.
3. If you're immediately working with them you should be in the same room with them. Or voice comms if you're in a remote situation, but I suspect most people working remote will work quite insulated anyway.
4. Yes.
5. If it's a message it can wait, messages are asynchronous communications. If it's time critical they need to call.
No, it should interrupt the team which owns that area of the codebase. If you're having an issue due to Postgres indexing, what value is there in pulling someone away from writing React.js hooks?
If your answer is "By making it painful, you force the problem to get solved." that is incorrect for the same reason that "If you throw a person into a 10-meter-deep lake, you force them to swim" is incorrect.
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?
In economic terms: if your main compensation is a fixed yearly salary, the most efficient use of your time is to expend the minimal amount of effort required to merely retain your job.
I hate to say it because i was trained to rise against forces and give my all 100% of the time, but in an env. Where the economic incentives are simply not correlated to productivity, I will not work more than nec. To not get fired.
Usually by then my efforts go to finding a new job, bc at that point i feel rather imprisoned.
These terms are too simplistic: there are other goods to be had. We have emotions, like it or not. Going home at the end of the day feeling proud about something is better than feeling like the day was a minimal-effort waste. Even if you had infinite time, you still have an opportunity cost by trading that time for n $MONEY when you could have nplus happiness.
I agree with you completely. I am referring mainly to the context in which you have practically no influence on your work environment. In such a case, hard effort becomes wasted effort.
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).
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.
Sure, having a nicer environment/project certainly is preferable, but sometimes you can't choose everything, and if you let the shitty outside make you do shitty work, then you might feel a lot more miserable.
Seriously. It's not just the environment. Most businesses discourage productivity by not rewarding it with raises, promotions, bonuses, stock or similar. In that case, it makes sense to be the least productive as possible. The less you work, the more you make hourly and the more energy, hopefully, you have got other things. Businesses that won't compensate properly deserve it and considering how rare raises are these days (outside big tech), this should be something almost everyone should learn. It's either that or work really hard to make less money than you did last year. It's the employer that's incentivizing this behavior, after all. That's how I've gotten a significant hourly raise without getting an absolute raise.
Being super productive is for people making bank and suckers.
I am already old and wrinkled youngster. Most skills that are required these days are just the latest new fad and will be forgotten about in a couple of years anyway.
This is true. Everything new technology seems like an evolutionary improvement on one or a few aspects of programming, like separation of concerns, expressiveness, correctness, etc. None of these things should surprise anyone unless they've been stuck in one of the 1990s 3.5GLs and never learned anything else.
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.
>What if I don't want to improve my productivity ?
I think you're reacting to the word "productivity" because it has negative connotations to some readers.
To others, "productivity" has neutral to positive connotations.
I think we all universally desire "less effort for more output" across work and leisure activities. We just don't like to label it "productivity". (I made previous comment.[0])
E.g. if a gardener wants to plant a row of flowers for pleasure, she might put all 10 flower pots into a wagon and then drag the wagon to the final location. This is more productive than hand carrying only 1 flower pot at a time and walking back & forth 10 times. People inherently like to be "productive" even for play and leisure!
>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.
I think you're being uncharitable in interpreting the blog essay. The scope of his tips is about being productive while in the office. (Ctrl+F search article for "office".) Therefore, finding bugs faster between 9-to-5 isn't going to detract from "playing" time on the weekend. In fact, it may even let the programmer leave earlier on Friday.
>Except for that part where they were spending free time watching play-by-plays of their own work.
About that, I only notice the article says this:
- "At the end of the week, I’ll watch a few segments from the previous week. "
I don't see why "end of the week" must be interpreted to mean "free time" instead of "end of the day on Friday before I go home for the weekend."
It still seems like some of us are determined to find reasons to dismiss the essay as detrimental advice because he used the word "productivity" as opposed to just charitably engaging the underlying concept of productivity as a universal positive.
This is a very unhelpful take. Some of us want to be more productive. Many of us want to be more productive so we can do more and still have more leisure time.
"Code should not be about productivity. Life should not be about productivity." does not help anyone. It's just empty platitudes. And even if it was true that people only seek productivity so they can devote themselves more to their job (it's not), why are you judging them and telling them your way is better?
Looking at your reply bellow you do seem capable of understanding the general question - you were coaxed into giving some productivity tips so why this empty response here?
I think you read way too much into that person's reply. They are questioning to basis of the article, which is something that should be encouraged, whether you agree it disagree.
I generally agree with this, but also disagree with this.
I think being forceful ("you are addicted") about how someone spends their time is the exact opposite of the approach you want to take. Yes, I regret many hours I spent on optimization, trying to do the best thing, trying to improve my productivity. I know that those things prevented me from focusing on what was really important - the so-called yak-shaving can dig you a hole of trying to do things really well.
But at the same time, I genuinely enjoy yak-shaving now. It's pretty fun. I'd say people are more obsessive over stuff than not, but it doesn't seem helpful to call them addicted.
For some people, programming is really fun and good. For others, balance is important. Nobody really can tell you what's important and what's not, except for that very question of importance.
I see people into spirituality and the like trying to force not-forcing on themselves. Being obsessed with work is not the best way forward (and a bit rigid), but also you sometimes have to do it. Sometimes being obsessed is fun and useful and actually gets things done.
I feel like I have toned down my disagreements as I write this comment, because life should really not be about productivity. But sometimes it should be. I in part do regret times that I spent optimizing stuff, but because I went through that, I now appreciate having less intent.
Who knows, maybe someone telling you you're addicted is what gets people to change afterall.
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.
> 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.
Yes :) The time saved should not be used to squeeze in more "code done".
On my side I've saved lots of time by simplifying the tools I used, reducing the number of dependencies, frameworks and other stuff and writing simple, "childish" code.
I'm a web developer. I prefer to do simple Ajax, HTML, pure JS and simple CSS and a good framework such as Laravel. For 80% of the projects its enough to "do the job". If the client wants a "nice looking date picker" just go for the default HTML one, saves hours/days and the difference is minimal.
I've stopped looking for "new shiny" tools. In the end people are just looking for simple stuff that works.
Look at Hacker News for example. Minimalist. But "the job is done".
This is naive, but many - especially young people fall for it, their enthusiasm is exploited. All progress is priced in immediately, this is the lection everyone learns - or should learn - after a few years at least.
Having the intent to improve often destroys the process itself. It's very subtle and case-by-case, but a bit of leisure and leeway with work is good. I do like monitoring myself, but only if I am kind of just enjoying it? Not really trying to "improve" per se.
Well, that's a charitable take, but he literally starts with "stop reading slashdot/hacker news", so it's clear he means keeping your nose to the grindstone while you're "working".
I agree with you 100%. Improving my productivity for 20% will not give me a 20% salary raise, since those two don't actually correlate.
It would just make me more worn down and exhausted when I leave the office, and require would longer recovery time afterwards, thus eating my free time.
If the corporates don't want to compensate fairly for the extra productivity, then the optimal solution is to do a bare minimum of productive work and minimize own efforts to be able to focus on things that really matter to yourself.
> It would just make me more worn down and exhausted when I leave the office
Only if you're working harder. Generally when people talk about productivity-boosts they mean working smarter. That may mean stopping doing things that are just making things needlessly difficult.
The example in the article is a good one:
> I would write all my code for a new feature up front and then test all of the code collectively
Knowing that this is a bad approach is an important lesson - doing things that way creates frustration and wasted effort, and likely harms quality, with no upside.
Another example might be with organisation skill: if you're working in self-made chaos, it's more tiring, more frustrating, and it's less productive and harms quality.
If you're getting fired for not being the perfectly optimal worker automaton, then I'm very sorry you ever had to work for such a business in the first place.
I don't know if your intent is to come across as sarcastic or as genuinely sympathetic here. If you were going for genuine sympathy, I'd like to explain why your words sound dismissive:
Taken literally, words like "perfectly" or "optimal" refer to an absolute.
Human life is very rarely absolute. We deal with ambiguous information and must make choices which are trade-offs among competing values we simultaneously genuinely hold. This is such a recurring fact of human life that people sometimes use absolute words as an exaggeration, as I think you did here. That exaggeration expresses emotions like exasperation and incredulity. It says, "it is utterly ridiculous that your job even had those unrealistic expectations of you." That is the literal meaning of what you want to say with the words "If you're getting fired for not being the perfectly optimal worker automaton", right?
If I was talking about how my workplace had ridiculous expectations of my output, that would be an expression of sympathy. But I am not, so it is not.
The other thing that exaggeration does is refuse any thought about magnitudes. Without a sense of magnitudes, you can't hold the information you'd use to decide on a balance. Exaggeration is a refusal to acknowledge problems of balance. True sympathy acknowledges the realness and difficulty of the problems faced by another.
Incredulity sounds more like, "I don't believe that your problem is real."
----
Maybe you think I'm incorrect.
Maybe you think there isn't a balance to be struck.
Maybe your life experience has shown that this balance is obvious and easy for you.
Thats fine. You're free to disagree.
But if you do and sarcasm was your intent, please know that it is both less clear and less kind.
You are improving your productivity by 'doing something else', such as 'walking for several hours in the forest'.
Banging your head against a problem for several hours while not making any progress is frustrating. Not because you are 'unproductive' in the sense of producing value for your employer or customers, but because you are 'unproductive' in the sense of not achieving the progress you desire.
Thus we want to improve our productivity. Not because we need to be productive in a capitalist sense, but because we want to be productive to have the feeling of achieving something.
Whether increasing your productivity comes in the form of going for a walk or getting rid of distractions doesn't change that.
I don't know, my friend. What I'm about to type will sound a lot like Dudism ... here goes:
It's impossible to explain Wu Wei in instructional format. This paradox alone is its appeal and weakness. The concept is this: never force anything. But then also: do not slack off. Be keenly aware of what is desired but don't attempt at it directly, forcefully. Rather be content that "it (whatever you are seeking to achieve) will happen when you are ready to let it happen" by you doing something quite orthogonal/oblique to the objective.
It's an Eastern philosophical principle but I think there's a nugget of science that could be distilled out of this if studied for factors influencing success and failure in personal endeavours (that is, if any study were to be conducted - I know of none, btw).
From a personal experience I have great moments where I don't chase deadlines or impose mental pressure to conform to explicit design objectives. In these cases I would openly admit that what I am about to do may NOT be the thing I should be doing but I'm doing it anyway to see what might come of it (always keeping in sight the original premise or objective). I've noticed too that if I force a design too literally, I soon develop neurotic anxiety about handling exceptions my forcefully created universe of abstract correctness (abstractions are gon leak!).
You cannot force Wu Wei ... that will be both ironic and paradoxical.
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.
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.
Amount of work done is a poor way to phrase it. I mean something more along the line of "business value produced".
My previous job was leading a team responsible for scaling a Postgres cluster with ~1PB of data. A number of big wins would come from relatively small changes. You can apply the post just as well to finding the biggest wins in the shortest amount of time.
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.
> 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.
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...
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.
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")
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.
> 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.
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.
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.
> 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.
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.
> 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.
Yeah, from personal experience (and from watching others), a lot of the habits like the ones the author cites last a few months and then you end up dropping them for whatever reason.
You mildly contradict yourself in saying your innate productivity is impossible to write about and then mention it requires identity trade offs. The mastery curve has always been described as going from conscious to unconscious grokking and these blogs are the fodder for thinking about what works and what doesn't.
> 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.
But isn't it the only approach if you want to find that custom tuned productivity system that is right for yourself? Trial and error, listening to young people who might not have "gotten it" but might have discovered one missing nugget that will get you over your next personal threshold? Isn't a more fragile approach to look at a persons age and say "I'm older than x so I have nothing to learn from this young one with their silly conscious system".
The issue is novelty effect. People inexperienced in improving their own productivity will try an intervention, see great improvements in the following days, and decide to blog about it. But the improvements usually come not from the intervention itself, but from the novelty aspect - so they tend to disappear within a week. After suffering from that many, many times you finally learn the pattern and stop blogging about random things you're trying.
That said, trial and error is definitely the way to go, and I like to read about systems people develop from themselves - sometimes I discover a weird trick that sticks with me for longer.
The points were good, especially the one about writing a lot of code then wasting time trying to find the bug. I've actually seen people work like that and it drives me nuts.
I think you're right that the author is young, but that doesn't mean the observations aren't useful for those who haven't figured some of this stuff out for themselves.
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.
> 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.
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.
Sitting through pointless meetings is, to me, far more draining than tracking down a bug or implementing a new feature - I sometimes have to actually pinch myself to force myself to stay awake.
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.
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?)
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.
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.
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.
>> 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.
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.
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".
https://obsproject.com/ is win/linux/mac and really good for this because you have a lot of options for compositing what you want to record e.g. include front-facing camera and mic which can be very revealing about body-language, facial expression and erm.. muttered expletives.
If we were working with a friend and saw the extremes of body-language we sometimes display obliviously when things are not going well, we would instantly recognise them as a cry for help and step in. When alone, we are liable to just dig a deeper hole.
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...
I'm also interested in a tool like this. I think it could be very interesting to combine with a recording from a webcam as well. I know what I'm going to see if I start with this though. I'm in a disassociated state, procrastinating or avoiding thinking about work more than I do actual work throughout the day.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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)
"Your" is an unfortunate trope of internet titles. I think there's some hard-wiring that makes us respond to loud uses of "you": hey you!
The simple fix is to replace second-person titles with first-person titles. I've done that above. Now we can discuss the more interesting things in the article.
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.