Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.
Don't wait until next year. Start programming now. School is good to learn computer science; school is not needed to learn how to program. Don't read anything into the 5 lines of code per day. This is a pretty old article and even then, that would only be a reasonable figure if you take a large number of people on a large project and compute an average for everyone. In other words, counting refactoring, fixing bugs,…
I have already started programming, it is just that all the problem sets I have solved were easy enough that I could get to coding right away, and when I couldn't I just thought I was dumb
Day What I Did TotLOC --- ----------------------- ------ Mon Prototype Possibilities 300 Tue Write Building Blocks 900 Wed Construct Major Content 1,700 Thu Add Features 2,200 Fri Refactor, Test, Deploy 300 Customer: Looks great. Thank you! Boss: Only 300 lines of code in 5 days? Boss: How can you be more efficient? Me: I could take Fridays off.
I don't understand; your numbers add up to 5400, not 300.
There was a MOOC on Coursera called "Irrational Behaviour" and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to…
I think it's more complicated than this Locksmith example. I think we are so used to being ripped off by "experts", many
with a lot of spinach behind their names; We start to think
everyone is trying to make the most amount of money they can
out of a situation(usually a bad situation). I have no problem paying someone for a job well done--if they do it
quick all the better. The problem I have encountered is the
expert did the job, but it was a half ass job and their mistake didn't show up until later. I'm now kind of jaded.
One other thing about experience. I have found experience
doesn't matter quite as much as I thought it did in a lot
of professions--especially the professions that are a mix
of science, and art--like medicine, and yes Programming. A little experience, but
still double checks their work, and is staying current--Gold mine! The pillar of their profession, with an ego to match--I run! (I noticed someone brought up the mechanic and the hammer story. A stuck pinion on a starter sometimes responds to
a hammer blow. I used to position a long dowel(broom handle)
on the stuck starter through the engine bay and whack the dowel with a hammer.) Oh yea, I have found that people who
don't overcharge(whatever that even means anymore) are well
liked amoung their peers, and customers.
But sometimes you can see the possible abstractions only after the fact... I often end up deleting a lot of my own code that turned out to be unnecessary.
Then there's the situation in industrial control systems where sometimes you really itch to do that, but you can't because the return statements mess up the tight timing :)
Can't you use stuff like gcc's __attribute__((always_inline)), or just straight-up C macros, for cases like those? Worst comes to worst, you can always use m4/cpp/some other preprocessor, although that does tend to hurt...
Day What I Did TotLOC --- ----------------------- ------ Mon Prototype Possibilities 300 Tue Write Building Blocks 900 Wed Construct Major Content 1,700 Thu Add Features 2,200 Fri Refactor, Test, Deploy 300 Customer: Looks great. Thank you! Boss: Only 300 lines of code in 5 days? Boss: How can you be more efficient? Me: I could take Fridays off.
I don't understand; your numbers add up to 5400, not 300.
Total lines of code kept increasing until he was able to refactor everything on Friday and cut them back down to 300.
Day What I Did TotLOC --- ----------------------- ------ Mon Prototype Possibilities 300 Tue Write Building Blocks 900 Wed Construct Major Content 1,700 Thu Add Features 2,200 Fri Refactor, Test, Deploy 300 Customer: Looks great. Thank you! Boss: Only 300 lines of code in 5 days? Boss: How can you be more efficient? Me: I could take Fridays off.
I don't understand; your numbers add up to 5400, not 300.
The final column isn't LoC written that day; it's LoC in total. Friday was spent refactoring (what we in the old days called "rewriting", before the hipsters made it cool); taking the code that was already working, and making it smaller, lighter, better.
The meta message of the parable is programming is, in actual practice, an art, not a vocation or profession. For political / economic reasons we sometimes have to pretend its a vocation or profession, but it really isn't in actual application. Software architecture should be in the "fine arts" department at university, not a branch of finance, engineering, or math. In art, people expect the highest quality producers…
While software architecture certainly is an art, I would not say it is unique in that aspect among the fields you mentioned. Both engineering and maths should be considered art in their own rights.
If you consider abstract mathematics, it is easily seen that many mathematicians find most of their inspiration in the aesthetics of their ideas. Somehow the way we teach maths obscures this fact from the students.
Oh, and if you didn't already: Read «Zen and The Art of Motorcycle Maintenance». Aside from being a great story, it goes into detail about how technical work becomes art when done with Quality in mind.
A lot of people seem to think this is a story about programming. It's not. It's about perceptions.
A good programmer knows that a certain portion of his work is managing perceptions. This is part of a skill-set known as 'soft skills' and will get you farther than a perfect understanding of monads.
I don't believe some parts in the story. 1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data. 2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experie…
If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem.
Good, then they'll pay you again to write it a second time. As the Demotivator definition of consulting puts it: "if you can't be part of the solution, there's lots of money to be made prolonging the problem."
This is a parable about whether you really understand the nature of the problem, or not. If you do then you can produce a concise definition (i.e. a better program in fewer LOC) and if you don't then it can get much more complex. It's like the difference between trying to make a machine fly by making wings out of feathers and having it flap, or understanding the principles of aerodynamics and making a fixed wing out…
> However, for most non-trivial problems understanding everything up front isn't possible.
You know, people keep saying that, but I'm yet to find one example of it on real life. Yes, there are contexts with many rules, but I never found one that you couldn't modularize into person-sized problems.
That said, for several times I've solved in a month or two (took six once) problems that other people struggled with for years in the "corporate way" of development without any kind of success.