Counterpoint to this: a lot of the programmers I admire all have an uncanny ability to just sit and work for long periods of time. Like, sit down and hardly move for 10 straight hours. They achieve a huge amount in that time - much more in a single 10 hour stretch than they would in 10x1 hour sessions.
And that applies to other things they do: playing video games, reading a book...when they do something they go 'all in'.
I feel like this level of focus is much more of a superpower than small amounts every day (although that too is powerful, and both approaches are infinitely better than what most of us do, which is very little)
I certainly agree. However, many people don't have that dedicated focused time. I wanted to give an alternative perspective on what one can do when you can't find such long stretches of time.
Any tips on how to change the timestamp on your Git commits? That way you could get your work done on a Monday and spread the commits out throughout the week. I've looked at this before but there are two timestamps on each commit (can't remember now what each of them denotes) and I could only change one of them.
Whatever we do, please do not solve the actual root issue under any circumstances. That will not do. We need to stick another layer on top of the pile so we can have conferences and hashtags about it.
There will have to be something to solve all the problems that are created by Kubernetes, which itself exists to solve the problems with Docker, which exists to solve the problems with VMs, which exist to solve the problems with Operating Systems.
I can't wait for the next layer of complexity to be added. It will no doubt be called something like WizzlyBobATron.
> I'll come up with my own tools. They won't be great, but...
They WILL be great. They'll do exactly what YOU need them to do, and nothing else.
Software at present is a disaster, partly because we're just piling on complexity all the time, thinking only of the benefits and never of the huge downsides ("fighting with tools").
Everyone who develops a tool did it because they thought their tool would be great, and do exactly what they needed better than everything else that existed previously.
Everyone has slightly different needs, so that is exactly what creates the complexity disaster you are talking about. I think that being more willing to re-use the existing work of past developers actually works to reduce this problem.
That's true, and personally I'd much rather fight with my own code since I usually 100% understand what it does.
In a team of course it would be different - unless I perfectly document my own code, my colleagues would be better off with something they can actually google.
