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.
> 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.
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?
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).
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.
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.
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.
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")
> 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.
> 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 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.
[+] [-] pritovido|6 years ago|reply
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.
[+] [-] hyperpallium|6 years ago|reply
That's why we have products (including open source tools).
[+] [-] einpoklum|6 years ago|reply
[+] [-] FreezerburnV|6 years ago|reply
[+] [-] hyperpallium|6 years ago|reply
[+] [-] modamilk|6 years ago|reply
Can you elaborate on this? I have never heard of any efforts to automate bug discovery beyond static code analysis tools in IDE's for example.
I agree with your first and last point though. Cheers
[+] [-] decebalus1|6 years ago|reply
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.
[+] [-] afarrell|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] malisper|6 years ago|reply
> 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.
[+] [-] clktmr|6 years ago|reply
[+] [-] stared|6 years ago|reply
There are exceptions and emergencies (then, and only then - unscheduled phone calls), but only in case when it is worth canceling all daily progress.
[+] [-] cjfd|6 years ago|reply
[+] [-] Cthulhu_|6 years ago|reply
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.
[+] [-] collyw|6 years ago|reply
Why should I bother about making myself more productive when so many factor outside of my control are doing the opposite?
[+] [-] swsieber|6 years ago|reply
Lots of things opposing a worthwhile attribute in your life makes your own efforts in that area more important, not less.
I'd rather in control of my own development, even it requires more deliberate effort than if other external things were removed.
Plus, it seems plausible that you will one day find a job which removes those things. Why wait?
Of course, this presupposes that you think being productive is a worthwhile thing independent of your current job.
[+] [-] slumdev|6 years ago|reply
[+] [-] mnm1|6 years ago|reply
Being super productive is for people making bank and suckers.
[+] [-] moretai|6 years ago|reply
[+] [-] edhelas|6 years ago|reply
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.
[+] [-] vnorilo|6 years ago|reply
The machine and the human both do less work.
[+] [-] multiplegeorges|6 years ago|reply
He empirically discovered test-driven development!
[+] [-] JoeAltmaier|6 years ago|reply
If we ignore critical process differences, then sure everything is 'like' everything else.
[+] [-] jspash|6 years ago|reply
[+] [-] TeMPOraL|6 years ago|reply
[+] [-] ivanhoe|6 years ago|reply
[+] [-] phodge|6 years ago|reply
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|6 years ago|reply
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|6 years ago|reply
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/
[+] [-] jackkinsella|6 years ago|reply
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")
[+] [-] cranekam|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] luord|6 years ago|reply
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|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] bucket2015|6 years ago|reply
That said, I did manage to stick to an explicit system for a bit over a year now which produced some imperfect but adequate results: https://blog.maesure.com/2020/02/01/anti-procrastination-sys... (disclaimer: my product blog)
[+] [-] friendlybus|6 years ago|reply
[+] [-] mnsc|6 years ago|reply
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".
[+] [-] ChrisMarshallNY|6 years ago|reply
[+] [-] celticmusic|6 years ago|reply
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.
[+] [-] thecleaner|6 years ago|reply
[+] [-] angarg12|6 years ago|reply
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|6 years ago|reply
[+] [-] commandlinefan|6 years ago|reply
[+] [-] adamzapasnik|6 years ago|reply
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|6 years ago|reply
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|6 years ago|reply
as a result i brushed up my vim scripts and put them here: https://github.com/MoserMichael/myenv/blob/master/VIMENV.md
[+] [-] wakatime|6 years ago|reply
[0] https://wakatime.com/
[+] [-] neonate|6 years ago|reply
https://archive.md/nq3wD