Doing more vs doing better programming and how to avoid burnout

#todayilearned #career #programming #agile

TL;DR notes from articles I read today.

The best way to get better at writing software is to write more software, not to seek perfection at every shot.
Put more thought into your design systems - strive to write readable, maintainable code without bugs.
Don’t assume that you will one day churn out beautiful code effortlessly. Instead, learn to review and test more thoroughly and refactor sooner than later.
Quit the struggle of trying to get faster at engineering. Taking your time to think and revising as you go helps you write better code.
However, realize it is impossible to do the last while meeting objectives; instead, apply diligence over the long-term.

Full post here, 4 mins read

Look at how professional athletes build their careers. They pace themselves to optimize performance and ensure the longevity of their careers. We, software developer can (and should) do the same too - use the model of stretching, executing and coasting just as they do.
Stretching is the most fun mode where you learn things quickly, apply them as you go, step up to new challenges, and move out of your comfort zone to accelerate learning. However, if you stretch too long and you will slow down or burn out.
Executing is the normal way of working where you use your existing skills and experience to get things done well, without continuously stretching. To get your manager’s support on this mode, list additional things you do and establish your intention to delegate or say no.
Coasting implies doing less or lower-quality work than you are capable of, say, as a short breather after a big project or because of personal circumstances.

Full post here, 5 mins read

Design the project so that introducing changes is not expensive.
Don’t spend too much time designing. Start building, learn and progress. Build in feedback loops in every development cycle.
Don’t mistake fast initial development for sustainable agility. You want to arrive sooner at the right end product rather than simply going faster.
Work in smaller teams, as bigger ones are less flexible and need more communication making them less agile. Know that more people does not guarantee earlier completion.
Avoid using speculation on future requirements to add complexity to projects. However, past changes can be clues to future needs, so watch for change hotspots and high defect density.

Full post here, 6 mins read