I find Beck to be mostly spot on, enjoyed his books on smalltalk and unit testing back in the days. I get the feeling that he couldn't care less who is a master according to what measure, he's just trying to make the best use of his experience by doing and sharing, which is the the only thing that makes sense once you go deep enough down the software rabbit hole.
Mastering Programming (2016)
11–20 of 123 posts
Re: Mastering Programming (2016)
#12If you know you will be stuck working on something for a while, spend a little extra time on each progression, like solving edge cases, performance issues, compatibility, and writing automatic tests for regression. That way you can spend more time on actually adding value, rather then catching fires and debugging.
Re: Mastering Programming (2016)
#13Make it run -> make it right -> make it fast
Making it run right is usually the hard part. I say 'run right', because if there is an assumption (explicit or tacit) that 'make it right' is a matter of relatively small incremental fixes to running code that is fairly close to being right, then this aphorism is coy about where the hard part gets done.
I am taking 'right' to mean 'correct', and not some lesser metric of quality, or an aesthetic preference.
For those cases where making it fast is the hard part, one could make the same argument, perhaps even more clearly. Having something that runs, but which uses an algorithm that will never be fast enough, could be the first step down a long dead-end.
Re: Mastering Programming (2016)
#14Make it run -> make it right -> make it fast
This is good advice in general, and so it amuses me when i come across problems which invert this order. Now and then, you can say "if we could do this thing that currently takes time T in T/100, it would be a game-changer" - it would enable whole new approaches, businesses, etc. In that case, your primary goal is to make it fast, and if often doesn't matter if it crashes, fails, or gets a slightly wrong answer 10% of the time, so you start by making it fast, then improve the code, then work on the improved code to make it reliable.
Re: Mastering Programming (2016)
#15If you know you will be stuck working on something for a while, spend a little extra time on each progression, like solving edge cases, performance issues, compatibility, and writing automatic tests for regression. That way you can spend more time on actually adding value, rather then catching fires and debugging.
And if you're new to a team or a company, do not underestimate the value of confirming documentation and test cases(if they exist!) and improving upon them if it's possible. This helps in multiple ways: you gain a reasonable understanding of the codebase through reading and testing; you are immediately contributing value to the team by improving upon the process and making it easier for you to onboard new people when the time comes; you gain the confidence of your team by showing interest in details that may have been overlooked for significant periods of time, allowing cruft to build up and plenty more.
Re: Mastering Programming (2016)
#16Make it run -> make it right -> make it fast
This is good advice in general, and so it amuses me when i come across problems which invert this order. Now and then, you can say "if we could do this thing that currently takes time T in T/100, it would be a game-changer" - it would enable whole new approaches, businesses, etc. In that case, your primary goal is to make it fast, and if often doesn't matter if it crashes, fails, or gets a slightly wrong answer 10% o…
If it currently takes time T, then it already runs and probably runs right, otherwise you likely wouldn't care about cutting time. Rule still stands.
Re: Mastering Programming (2016)
#17Distillating years of experience in such tiny concepts is a bit harsh on the reader. Without any concrete example, the advice could easily be very misunderstood, or not understood at all. Being a fairly seasoned developer myself, I kind of intuit what they mean, but I could very well be projecting what I think I am doing right into each of these, and conclude that I'm a master programmer... yay!
yes im part of the master programmer club too, unfortunately though, i will not live 3e9 seconds :( and certainly will not have 3e9 seconds in my life to spend on programming.
That's about 95 years... You probably won't spend that much time programming, but you could live that long.
Re: Mastering Programming (2016)
#18Seems too abstract to be of value to people who are looking to improve themselves.
Re: Mastering Programming (2016)
#19Distillating years of experience in such tiny concepts is a bit harsh on the reader. Without any concrete example, the advice could easily be very misunderstood, or not understood at all. Being a fairly seasoned developer myself, I kind of intuit what they mean, but I could very well be projecting what I think I am doing right into each of these, and conclude that I'm a master programmer... yay!
This is the crux of the problem with a lot of software engineering culture as it stands today - blog posts and talks frequently deliver abstract concepts that only really make sense to people who have already grasped/discovered those concepts.
The enlightened sit nodding along, while the unenlightened go away confused or misled. Positioned this way, half-understood ideas frequently do more harm than good.
TDD is a great example of this.
In this case, though, I think the article does a fairly good job - it highlights productive ways of thinking that will incite useful self-reflection ("Do I do this? Could I do it better?") rather than half-communicating ways of doing.