Design makes better software with current coder capability.
Practice makes better coders.
When you pull one factor responsible for success out and write about it, suddenly people miss the point and believe that what you are saying is that This is the ONLY important factor in the success. I donât believe this is what you are saying, Jeff, not for a minute.
The point is that repetition is vital here. Larry Bird wasnât such a tremendous shooter, particularly from the foul line, because he only took foul shots - but he did shoot a lot of them⌠Iâve read stories of his focus and determination to be better at hitting those clutch free throws, and he was able to do it, in part, because he was committed to being the best.
Writing code is no different. Iâve written tens of thousands of lines of code over my career, probably hundreds of thousands of lines, and my success is due, in part, to the fact that Iâm IN THE CODE on a regular basis. That is no different from being a concert pianist or a great tennis player. You have to DO IT to get better. When Iâm not under a heavy timeline crunch, Iâll challenge myself to take 30 minutes to an hour a day to learn something new and implement it in code. Beyond having an ever-increasing toolbox of solutions for those yeah, Iâve done that before⌠moments, it helps me be a better coder, helps me to strengthen those good practices and ultimately makes me competitive in the marketplace. If I fiddle-farted away my time doing the bare minimum, I suspect my quality and effectiveness would suffer.
Good post, Jeff.
Thatâs why I love this blogâŚ
Completely agree.
YES.
The worst programmers I know have been people who only write code and are generally deeply unreflective, and in that context, I would agree with the critics who say that more doesnât equal better.
However, most of those programmers are lost causes anyway. Vastly more damaging are the huge amount of reasonably talented programmers I know who are so wildly hemmed in by the vast amount of decontextualized received wisdom and best practices and moralizing regarding programming they receive and believe that they become the equivalent of grammar nazis - people who nitpick tiny one-size fits-all context-free rules without ever really writing enough code to start learning the deep complexity of their own specific and particular domains. Theyâre too afraid to of doing things wrong to ever learn how to do things right.
I think the craft observations are very apt. Itâs almost as though a lot of programmers are upset that they might be engaged in something involving craft and holistic right brain thinking. Richard Gabriel writes a lot about this (and especially the importance of reading lots of other really good code, which far too few programmers actually do). Maybe itâs just the ironic nature of programming - our entire task in programming is to make knowledge hyper-explicit and executable, and yet, being humans, huge amounts of own productive capabilities have to come from that part of brain that can deal with amazingly deep patterns and structure non-verbally (you see this all the time with genius mathematicians who reason visually but then cover their tracks by translating back into the symbolic).
Looks like a lot of people missed the point here. The point is that good stuff can only be produced after a lot of practice.
There is no substitute for experience. Thatâs all the point is.
Itâs odd that some people seem to think that quantity means create lots of software and quantity means make software thats better by really thinking about it
In this instance, it seems to me that the point is that (quantity of code)iteratively writing software, release when complete is better than (quality of code)do the design, write the software, release.
Clearly the first way will create better software, simply because it allows the changing requirements of a client to be absorbed.
Im also surprised noone used the monkey analogy. Infinite numbers of monkeys would write the whole works of shakespeare in the time it takes one monkey to type the neccesary number of keys, but it took shakespeare a lifetime to do, probably because he had to really think about what he was doing.
Yeah sure, and âworking harderâ always trumps âworking smarterâ.
Man, things are relative and thus most of the time if you use âalwaysâ in a proposition/decision/policy you make you are bound to be proven wrong.
The main thing that most developers lack is the ability to âdo a good jobâ. Obviously the definition of âgood jobâ depends largely on the context, but anyone knows a âgood jobâ when they see it.
Other times you have to work smarter, other times you have to work harder, the basic ability is to know when and how to compromise between the two and that comes from experience and sometimes itâs a natural talent too.
But I have seen many a programmer that just donât get that and keep on following a set of ALWAYS and NEVER rules (some others just donât get programming in the first place, but thatâs another story).
I always wrap everything with C++ classes!!! It improves the code!
I always write the most efficient code possible.
I never write comments; comments need maintenance.
I never use ASSERTs, they make you sloppy. I just make it right from the start.
=)) Itâs like Iâve been saying since I was about 16 : The road to becoming a good programmer is paved with bad scripts. ;
I do not have a problem with this mentality, so long as oneâs aware that youâre responsible for your lack of quality. If it leads to problems, thatâs your fault, no one elseâs. If you canât fix it quickly enough, thatâs your fault. If it leads to someoneâs harm, either financially or physically, or what have you, then thatâs your fault.
A writer writes, a painter paints, and a programmer programs⌠but a writer does not write great novels by scribbling on napkins, and a painter doesnât sell his doodles in the margin of the daily paper. Likewise, a programmer does not become great by pumping out quantity code. A programmer becomes great through quality code.
So itâs your choice, make a living, or strive to be great.
I think you are totally correct. I see the phenomenon of over-theorizing in so many walks of life. For me I see it in programming and in music.
I donât think youâre saying it isnât good to plan things out or it isnât good to use established techniques (in other words you would not advocate writing spaghetti code with GOTOâs everywhere),
what you are saying is that some people over theorize and indulge in a certain kind of neurotic inhibition: OMG IS MY DESIGN ABSOLUTELY PERFECT? Before they even begin writing code.
Better to come up with a good design, and not worry whether it is absolutely perfect, and then go ahead and code it. Then you learn from your mistakes.
In the words of G.K. Chesterton, If a thing is worth doing, it is worth doing badly. I think he meant to say if you are inhibited by over perfectionism or in this case over-theorizing, you really need to just jump in and do the best you can. Youâll learn from your mistakes.
Regards,
-Derek Andrews
p.s. I notice a lot of this design neurosis in music also. People talk endlessly about harmony and theory and spend too little time trying things out. It isnât that learning harmony and theory is wrong, it is just that getting too neurotic and perfectionist about it will stop you from learning as easily.
Is 10 people with 1 year of experience really equal to 10 years of experience? To take this a little further, I am sure those monkeys will write Shakespeare. There just needs to be more of them.
âTomS
The phenomenon of excessive theorizing is strange in itself. For all the books and theory published since 1993 (as an example), very little has been added to the pool of theoretical knowledge. You can cover a lot of ground (still!) with books by Stroustrup and KR at the conceptual level (just two books). Design Patterns is a great book, but poorly written. So we are now at three books of theory. If you repeat this process, you may find another 3 books to satisfy your tastes.
Books such as Learn to Space Travel in 21 days do not count. You are better off experimenting that following a narrow-minded book for 21 days (or chapters).
Six books. Big reading list
Daily, I see a huge difference between people who can execute on their ideas and people who just spin their wheels and whiteboard endlessly. If you have a grasp of some basic theory, you can produce great code in 2-3 iterations. More than 3 iterations would be an indication that chosen approach is not the best. It may not be wrong altogether but there is a better one out there
What I would say is: take about 80% of the time you would spend on process and theory and spend it actually thinking about the code you are writing. Sitting there, with your editor open, executing each line in your head. Execute all conditions for your conditional statements in your head before you actually code them.
If you donât do that, why bother with the other stuff?
Of course, this goes for everybody in the organization. If testers donât search the bug db for existing bugs before filing new ones, whatâs the point in testing? If product managers donât talk to customers before proposing features, whatâs the point in working on the product at all?
Craft is probably the best definition, although it does smack of little old ladies weaving wicker basketsâŚsometimes software development can raise itself to the level of art, no?
âAfter a certain level of technological skill is achieved, science and art tend to coalesce in aesthetic plasticity and form. The greater scientists are artists as well.â (Einstein)
@matthijs
Itâs not even true for pottery (all forms of pottery more complicated than the crudely decorated blobs of the early stone age were learned from others, not arrived at through trial and error)
This comment is blatantly not thought through, because in order for it to be learnt from others, the others must have used trial and error. At the end of the day, the only way to do something better is to do lots of things and see what works best. You can use other peopleâs ideas to guide your work, but remember, at some point, they just DID it and checked to see what happened.
And for those saying This just means youâll release buggy code, face it, youâll release buggy code ANYWAY.
Frankly, Iâd rather have code that someone had thought about for an afternoon, coded in a week and tested for a month; than code someone had thought about for a month, coded in a week, and tested in an afternoon.
Theyâll both be buggy, the difference is the code which has been tested will have removed the bugs that annoyed the user, the code that had been thought about will have removed the bugs that annoyed the designer. Iâll take a messy algorithm in the middle of a calculation and a chunk of code where the presentationâs tied to the business logic, over a button that crashes the program when you click on it.
let alone for something more complicated like writing or developing software.
This merely shows youâve never tried to make a mug in a pottery class.
classic hacker 101:
repeat a very basic sumb thing for some time to acquire or perfect a skill
applied to programming it could be renaming/refactoring some classes by hand instead of using the IDE feature that do that for you, or use your compiler only on the command-line instead of using the GUI, etc.
morality:
a dumb repetitive task can teach you a lot about the things you take for granted
However consider adding an additional task the next day which would work in software but not for pottery, tell group A to make all your programs work together, let group B continue to work on their program.
Actually, that sounds like a great programming game for a CS class. And Iâm not sure what the result would be.
But Iâd argue that Group A would probably say Why make them work together? Thereâs not much reason to link a program that calculates square roots of polynomials to a program that calculates your tax return. Thereâs even less to link it to a second program that calculates square roots of polynomials.
With one caveat, I would say this is completely true. Assuming that the creator in question is trying to learn from the project, quantity will trump quality any time. Another way to put it is practice makes perfect. However, one must remember that practice involves an attempt to make oneself better. If someone is just churning out crap, all theyâll end up with is crap. However, if youâre learning from your mistakes, the sooner you make them (ie: the more you put out) the sooner youâll learn. The example given holds because it was an art class and the students were there to learn. If they were just there to get a grade, itâs easy to shovel clay onto a platter and then straight into an ovenâŚ
This is also why hobby programmers are nearly always better than people who just do their programming at work. In a work situation itâs fairly imperative to write quality work, so there is extra pressure to worry about that. However, when youâre just following a hobby, the joy comes from the time that you spend doing it, not really the perfection of the end result. If youâre free to make mistakes (and learn from them) then youâll see a LOT more of the fruits of your labour. You can argue that some people have/make more time for it and give up other things, but thatâs the same in any aspect of life. Thatâs also part of it being a hobby.
Go ask the Spartans if quantity is more important than quality!
I was thinking along the same lines, but with Zulus and Brits at Rorkeâs Drift.
However, I suspect a Zulu would want to direct your attention to the Battle of Isandlwana. So donât get overconfident.
Funny, for all the drivers on the road, with all the practice they get, how come theyâre not all Formula 1 capable? Practice is more than just doing. Itâs a concentrated effort to improve. Thatâs why 1 day at an advanced driving school will teach you to be a better driver than 10 years of daily commuting.