Why Programming is Difficult
joearms.github.io
joearms.github.io
I am compelled to febreeze every bit of code smell I come across. I often rewrite large sections of working code into better structures, more readable/concise syntax, better naming of variables/functions, etc. and In the process I have at times introduced bugs.
But that isn't enough to deter me.
I feel like I've accomplished something but in reality I have done nothing. It's kinda like cleaning behind the refrigerator. You know it's dirty back there, but it's not stopping the fridge from keeping your food cold.
However, "You know it's dirty back there, but it's not stopping the fridge from keeping your food cold."
If you don't properly maintain your fridge and allow too much dust to build up you could end up burning out the compressor.
Everything needs to be done thoughtfully, in moderation, and with purpose.
1. Fridge dust compounds linearly with time. Technical debt compounds faster the more technical debt you have.
2. Most of us aren't in the fridge business. The downside of a burnt out fridge is probably a lot lower than the downside of a terrible code base.
Note that I assume basic documentation, proper naming conventions, and adequate testing are part of "working correctly". Those are the things you do as you write the code initially. It's the refactoring/rework/gold plating that you leave for later, only if you need it.
Need to strike a balance between Get Shit Done and leaving behind code that isn't a pain to maintain.
In fact, often the kind of abstractions I've created when I'm in that masturbatory mode described above, it turns out that the abstractions aren't worth it in the end because they're only used once, and it doesn't actually make the code cleaner or easier to maintain going forward!
But if I find the time to clean that code up---make it simpler and clearer, usually---then I find that I'm no longer fearful of touching that portion of code. I'm reinvigorated to fix bugs, add/remove features, etc.
So yeah, while the intangible effect is, "oh I've made the code simpler that really does feel good," I've also found tangible effects because I'm more motivated to work with that code in the future.
That's sort of like throwing a punch so hard that you throw yourself off balance.
I would suggest that you take that energy and first write unit tests or a code coverage tool or an assertion framework that doesn't intrude on production. (I've done all of the above, but I may have been "cheating" by using a language with exceptional access to the meta-level.)
This would allow you to refactor with greatly reduced introduced bugs. That would be more like keeping your balance thus staying in a good position to exploit an opening.
For example, I presently dance around about 6 projects. Only one really matters.
I have found that taking the time to rewrite the code that finally works into something that I can explain to myself in the future has paid dividends when I came back to it, and when I have not done that, we'll that can be annoying.
There is a time and place for code cleaning. If the code isn't something you are already working in, then leave it. If you are tasked to fix a problem or add something to existing code then cleaning it up is acceptable. Keep mind, I'm assuming there are tests written. Nothing pisses off your co-workers more than cleaning up working code and breaking inadvertently breaking something.
I can absolutely relate to that. It has happened that I find code so terribly written that needed to be modified. As nobody on the team actually understood how it was supposed to be working, I ripped it out, and rewrote it in a cleaner way. I knew this may introduce regressions, but I knew the modification I had to make would very likely do the same thing. But if there were going to be bugs, I'd rather have them come from a maintainable codebase.
> You know it's dirty back there, but it's not stopping the fridge from keeping your food cold.
Unfortunately, the more technical debt you accumulate, the more difficult it is to change anything. So, yes, enough dirt will eventually lead to "we can't do X because it's too risky/too much work". Ideally, we should all do some refactoring every week.
In fact a lot of software design is just for making things easier for humans. Otherwise we could have files that are 14,000 lines long.... The hardest part of software is the people.
Every idea brought to the table should have a counter argument, we should all carefully discuss the pros and cons of everyone's ideas, and we shouldn't hold so tightly onto a pipe dream because we really want to use xyz tech or because "we're used to doing it x way!"
If something is clearly better, safer, smarter, or mitigates risks that another idea doesn't then you need to accept it. I do not care how comfortable you are with your idea. It is time to switch gears and make the sensible choice based on the facts, not your personal bias.
This... I'm trying to work with someone whose only programming experience is with IDEs on Windows that hand-hold every step of the way. Something as simple as creating a file, compiling it and running it in a terminal is something he's never done.
I've spent more time trying to explain incredibly basic concepts than actually getting anything done.
For his prior apps (flash) he created objects using only a graphical interface (never wrote a single class), and the 'program' was a single 9000 line file where everything (all vars, functions, etc...) was in the global namespace with absolutely no organization, encapsulation, etc...
Anyhow, for someone who claims to have been programming for 10+ years, I'd expect some understanding of how the underlying technology works, how languages and compilers work, etc...
I mean, I like convenience as much as anyone (my Vim setup behaves like an IDE with code completion, automatic compiling, etc...), but knowing the command line is a good thing when the app you want to build involves a Unix-y server...
Don't mistake quantity of experience with quality.
Your fellow is abnormal to the extreme. That he's never met anyone in 10 years to tell him drag & dropping is not programming is one thing.
Making your description match a good proportion of C# developers or even Java developers just shows your irrational bias against types of programmer you obviously view as inferior.
The problem is not that he's using an IDE, the problem is he's not a programmer.
Bloody luddites clinging to their consoles.
It's not drag and dropping, it's using a 'visual programming' tool that the environment encourages.
> The problem is not that he's using an IDE, the problem is he's not a programmer.
I wouldn't disagree, I like IDEs myself. I even use automatic completion in my word processor. The problem is that he never learned the basics.
> Bloody luddites clinging to their consoles.
It's funny how things always come full circle - search is the big thing now, everyone has an interface based on search. Windows 8, Linux, OSX, Android, iOS, everyone.
We enter http addresses into our browser, and search for things using (gasp) text, but using the command line makes one a luddite. Great logic that...
As an example, I recently tried my hand at making a Chrome extension using the Yeoman build tool. It was a simple plugin to allow you, on Reddit IAMA pages, to hide all comments except those from the IAMA subject and their direct questioners, and to also auto-load all comments:
https://github.com/dannguyen/iama-highlights-chrome-extensio...
Figuring out how to use the yeoman build tool took about 30 minutes (it's not quite fully developed)...it took about 30 minutes to browse through the Chrome extension documentation and then think of what I wanted to do. About 10 minutes to write the actual jQuery.
...And then about 3 - 4 hours figuring out why the comment auto-loader wasn't working. I thought I could simply just have my jquery activate the "click" event on all "load more comments" links...but a recent Chrome upgrade clamped down on security, effectively sandboxing all extension code and preventing it from executing existing inline JavaScript.
IMHO, this is a good security measure. But it just goes to show you that when things are made "easier" (the scaffolding of the extension, the jQuery to do DOM/AJAX work), there are still intractable tradeoffs and details that have to be dealt with...in this case, security.
At first we had no environment, so we had to make it ourselves. A few companies did this, and turned into monopolies.
Then we started trying to make free/open-source environments to combat this problem, but they ended up so incredibly scatterbrained that compatibility is a very real and current nightmare.
The monopolies are trying really hard to give us good environments, but first of all they come at a cost, which isn't accessible to many (Apple's hardware, MS's software, etc). And secondly they are not community-driven efforts, so we have little control over them.
So the battle rages on between the plethora of options I have for a programming environment. Meanwhile I'm just trying to write some simple apps that help me pay the bills (we get dangerously close to not being able to each month) and the competition between environments only slows me down.
As for the compatibility 'problem', install the compiler/interpreter version you need from source, use chroot if you need to, etc... If you're making apps to run on said scatterbrained systems, you can ship statically linked libraries with the app, or use a cross-platform solution (Java, HTML5, something like Haxe, etc...).
By the very nature of the business, if you are not improving something, some human-describable human activity, by using esoteric magic, you're probably not that good. If you're making it indescribable in the process of making improvement, perhaps you've been in the business a long enough time to know, the only difference is whether the customer can be bothered to learn the language, or not. Anyone can 'program computers'; computers are a universal language.
This view point overlooks the fact that people don't have infinite time and resources for learning and/or creating stuff. It also ignores the role of specialization.
Learning how to garden has improved my code structure and how I think about relationships and similarities between things from learning about the relationships between different plant species, families and cultures. As well as looking at how they grow (it's very functional).
My point being that a lot skills overlap and I think we can master far more than we give ourselves credit for. But because we think it's not feasible few of us open ourselves to the possibility.
That's backwards. Not "anyone" can program computers. Anyone can try, but most will fail. Just like "anyone" can "do math" or "do chemistry" or "do anything", but most will fail. The reason programming is lucrative, whether as an employee or entrepeneur exploiting programmers' labor (or supplying their own technical labor), is exactly because not everybody can program well enough to meet a market need.
It's a curious thing, this misplaced, or in some cases faux-humility about programming, or any other academic/intellectual endeavour. It dovetails very well with certain business interests who would love for nothing more than programming to be as commoditized as, say, janitorial work is. These interests are definitely getting their wish in some areas (e.g. web/mobile development).
Programming rewards the rational, and compilers and bugs have no sense of survival that would make them relent in the face of intimidation. So programmers deal with compilers and computers on their terms: the unfailingly rational.
Humans are not computers. Humans do respond to intimidation---or rather, they respond to relative intimidation. Programmers are carrying tweezers in the fencing societies that corporations are.
No they can't. Anyone can try, most will fail, because few are suited for it.
If that were true, programmers would be making minimum wage and would be ranked alongside people who wash cars.
* Not everyone can program
* Of those that could program, only a small part of them *want* to program
Often with the most hilarious results.
However, the reality tends more often to be: - Frantic Googling trying to figure out the magic code to pass to a black box 3rd party component that will prompt it to spit out exactly what I need - Banging 3rd party components together to see what happens to be compatible - Trying to figure out how to work around the limitations of an API without being too inefficient or complex - Spending 4 times longer on conference calls discussing a problem than actually fixing it
* performance
* modularity
* correctness
* maintainability
* security
* functionality
* robustness
* user-friendliness
* programmer's time
* simplicity
* extensibility
* reliability
* scalability
The way I would put it is that programming gives a person more power to realize their ideas than any other device in existence, in that sense, programming is the easiest thing ever. But since programming put so much power at your finger-tips, it gives you more ways to shoot yourself in the foot than any other activity. So programming while avoiding the pitfalls can suddenly look like the hardest thing in the world.
Arguably humans have a natural facility with language. And I am inclined to believe that our ability to produce programs leverages that facility. But again, the upshot is we wind-up with a really big cannon that, if aimed at all wrong, blows our feet clean away.
Too often when problems like those mentioned by Joe are brought up in discussion, the (seemingly) majority of programmers argue that these are just complexities we have to deal with. Perhaps they're just the vocal ones. I admit, it is a pragmatic attitude, but I constantly daydream about an environment, both technical and social, where these problems mostly disappear.
Thankfully, we're starting to approach some solutions on the technical side with virtual environments, deterministic builds, etc.. The social side I hope will fall out of having better environments for reproducible behaviour. Although I believe a total solution is technically impossible (at least practically, e.g. requiring total system verification, managed behaviour, etc.), I think we can make a lot of improvements to the environments we currently use.
I cannot even imagine learning programming and not having instant access to learning material/answers to my questions.
Most programmer job is simply translate others thought to language that computer can understand. Therefore the difficult is never the programming part, but the understanding human being part.
Comparing to human ability making computer close to understanding human, civilization has developed much more advanced in manipulate human to think like computer, evidenced by all the gadgets surround us today. Comparing to programmers inventing new ways to make computing smarter or say closer to human, majority of corporate line of business IT programmers are merely temporarily filling the gap between human and computer, but for how long? There is no need exaggerate the Corporate experience, that's a translator job can be easily replaced by cheaper labor and eventually by smarter computer.
Now programming is hard because of the giant scale of existing open source codebases.
It's not just the libraries, it's the toolchains, the build systems, the versioning tools, and that's just the things I've touched myself.
Someone once compared classical mathematics with modern mathematics, with the analogy of open pit mining vs deep shaft mining. I think programming has followed a similar trend. Modern programming involves strategically using existing tools, combining them without making major modifications to any of them. Of course, this is just for the individual programmer working on a discrete task. There is still room to participate in or lead large projects.
> When I’d finished this article, I wanted to spell check the content. At this particular time emacs-ispell mode decided to that it could not find aspell, the program that I use for spelling checking.
Does emacs have a grammar sanity check as well as spellchecker?
/patrik.
Here's what's difficult for me, and what only gets more difficult as my own time grows shorter and I'm less agreeable to wasting it: Working on teams, under managers, within organisations. Sitting in the third meta-meeting that week, listening to posturers quibble over what Agile means, rolling my eyes thinking obviously it's anything but agile. Performance reviews and arbitrary subjectivity-based rewards dressed in time-consuming process they swear will make it more objective. Perennial "Strategic Roadmap Shifts", listening to yet another CEO spout boilerplate bullshit about how this is the one way to glory, never shall we mention that one from just six months ago - that never happened. And that means another project cancellation. Then one by one the coworkers you like the most get fed up and leave, until the day it's your turn to get fed up and leave. On to greener pastures to enjoy a few months of a semblance of accomplishment before the whole cycle starts to repeat again. All that is what never gets any easier for me. Like everybody always says, "It's the people!"
Now I'm in a senior role I spend most of my time explaining what has to be done. All the hows and whys take a long time to explain thoughtfully. If all you can do is "I'm smarter than you and I say so" that's not a good explanation.
I know we like to complain how meetings and presentations take up valuable programming time, but without them there's no way to explain to a CEO what unit tests are for, or why we're now adopting JQuery and removing Prototype from our 5 year old application.
It's always possible, but you have to be aware of what everyone else who supports your organisation values.
No one cares what your IQ is. There are many different kinds of intelligence and some of them, like social and emotional intelligence, also contribute to your personal success within any particular organization.
Mention of IQ induces reflexive invocation of multiple intelligences like ipecac, but IQ-style intelligence is directly relevant to programming.
High emotional intelligence makes it worse when you're in a toxic corporate environment.
I disagree that "only people who are overly concerned with and take advantage of mentioning their IQ". More likely, it's just that smart people with empathic intelligence don't mention it. You know, because they realize that others don't like feeling "dumb".
No one cares what vis IQ is, but they care how good ve is at programming, and ve attributed vis programming ability to vis IQ. Do you think that connection is false, i.e. that there is only weak correlation between programming ability and IQ?
Thread did not disappoint.
You do not understand "ordinary people." To you they are 'stupid fools' -- so you will not tolerate them or treat their foibles with tolerance or patience -- but will drive yourself wild (or they will drive you wild) trying to deal with them in an effective way.
Find a way to do your programming with as little contact with non-technical people as possible, with one exception, fall madly in love! This is my advice, my friend.
Perhaps we are governed by idiots. Yes, I'm sure that if we were governed by people with "HN smarts" and worldview, I'm sure society would be so much better off. After all, look at all the great things Silicon Valley and startups are doing to make the world a better place!
this is something i've always felt and was always confused by when I saw others coding. Nothing was ever "hard," coding just made sense to me. So logical, so easy to do, concepts may be difficult to grasp at first, but it never took long to grasp and commit it to memory.
(Sometimes things fall apart in implementation but we won't go down THAT route)
Most of the time software is fairly 'easy', find the source problem, map out a solution, use your design patterns, and then implement it. I am NOT book-smart by any means (and 5 years Marine Corps vs College did not help that(though going back now while working in the industry seems to be helping to fix it somewhat), however I've always clicked with programming. Sure at times I lack experience that someone who has 10-15 years experience in a certain language might have, but 90% of the problems really only need 2-3 years experience to come up with workable solutions.
I consider myself lucky though, my first job was re-writing an entire code-base to OOP with only one Senior Dev (who was hired a month after me) for guidance. And he taught me everything you could learn, involved me fully in decisions and together (yes a full team of two lol!) stood up Agile Development practices.
I really think that a combination of variously-challenging levels of work combined with an excellent mentor, and being treated as a full-equal is the key to training software engineers to be amazing engineers and giving that 'click'. But I will also say, it takes a certain type of person, some of the people I've seen in school will never be amazing, they lack the flare of passion, but I do believe that the certain type of person needed, is more relevant in Software Development.
But I would still add that I'm doubtful that someone can work on large projects and not have communicating and working with other people be an actual part of programming (rather than that "other problem", "people").
If your projects need you to produce code that other people will modify, I would claim that your coding is going to be a matter of communication. Perhaps you write one-shot firmware for toasters or missiles so this doesn't apply. But I think any student of programming in general tends to see the task as a process of communication and not just cleverness. On this subject, I'd recommend Steve McConnell's Code complete.
http://www.amazon.com/Code-Complete-Practical-Handbook-Const...
The other situation where communication is important is once you have a large enough application that you have to start dealing with other people's code and design.
There is a lot of hellish bureaucracy in even the best of these situations but I think there is none-the-less some important learnings available there.
A person with an IQ at or above 145, who is also fully conversant with reality, would know that IQ testing has a reputation nearly as bad the field of psychology that popularized the activity in the first place.
http://en.wikipedia.org/wiki/The_Mismeasure_of_Man
> 2) I've been practicing hard, 25 years.
A person of your age should know better than to use IQ as a point of argument -- assuming the IQ score is real and has created a tangible intellectual outcome.
With all respect.
I've never used my IQ as justification for anything, granted, but I had no idea it wasn't considered a solid measurement. I just assumed it was like most of the other tests I did well on, and filed it away.
You're paying more attention to it than I am.
Evidence trumps opinion.
http://en.wikipedia.org/wiki/Intelligence_quotient#Criticism...
> I've never used my IQ as justification for anything, granted, but I had no idea it wasn't considered a solid measurement.
It isn't remotely a "solid measurement", in fact it's a field surrounded by justified controversy on multiple grounds. The two primary objections are that (a) the tests favor certain population groups and discriminate against others for reasons other than intelligence, and (b) existing tests only really measure a person's ability to take intelligence tests.
> You're paying more attention to it than I am.
Yes, but I'm paying exactly the same amount of attention to it as the original poster, with a different perspective.
so the consensus in psychometrics is that iq tests are not systematically biased against particular groups.
and of course it measures a lot more than a person's ability to take intelligence tests". just look at the "social outcomes" section of the wikipedia page...
The flaw in the reasoning should be obvious to anyone but a psychologist -- the test outcome becomes a self-fulfilling prophecy, rather than an unbiased predictor of future performance. The contempt for science among psychologists is shocking.
> so the consensus in psychometrics is that iq tests are not systematically biased against particular groups.
Psychologists also came to a consensus among themselves (and, as usual, without any scientific evidence) that Asperger's was a real mental illness, and that Recovered Memory Therapy was a real therapeutic method. Fortunately, and to some extent because of these credibility issues, society is in the midst of dumping psychology as a serious endeavor:
http://www.nimh.nih.gov/about/director/2013/transforming-dia...
In summary, until there is some science in brain research, all this talk about IQ testing is overreliant on effects without any clue about causes -- on descriptions without explanations.
Notice the name of President Obama's recently announced program -- the "Brain Initiative", not the "Mind Initiative". The handwriting is on the wall.
That is false, and its falsity has been proven repeatedly.
http://en.wikipedia.org/wiki/Intelligence_quotient#Test_bias
Quote: "However, IQ tests may well be biased when used in other situations. A 2005 study stated that "differential validity in prediction suggests that the WAIS-R test may contain cultural influences that reduce the validity of the WAIS-R as a measure of cognitive ability for Mexican American students,"[123] indicating a weaker positive correlation relative to sampled white students. Other recent studies have questioned the culture-fairness of IQ tests when used in South Africa.[124][125] Standard intelligence tests, such as the Stanford-Binet, are often inappropriate for children with autism; the alternative of using developmental or adaptive skills measures are relatively poor measures of intelligence in autistic children, and may have resulted in incorrect claims that a majority of children with autism are mentally retarded."
Just one sample from a large literature on this topic.
> your language is alarmingly exaggerated and pompous for someone who lacks basic reading comprehension skills and is entirely ignorant about the subject of intelligence testing.
Nice argument. Do give us more samples of your logically flawed reasoning. The readers of this forum will surely appreciate your credibility sacrifice.
> Evidence trumps opinion.
I understood the parent to be saying that they disagreed that "someone that smart would have known IQ is bogus", not that they disagreed that "IQ was bogus".
Yes, and because of how the post was worded, we may never know. I suspect (and acted on the idea that) he was disagreeing about my claim about the veracity of IQ testing, but that's just a guess.
Let's look at the original exchange. The person to whom I replied said, "I've never used my IQ as justification for anything, granted, but I had no idea it wasn't considered a solid measurement."
I replied, "It isn't remotely a "solid measurement", in fact it's a field surrounded by justified controversy on multiple grounds" ... and more in this vein.
How is that in any way ambiguous? It's a discussion of the credibility of IQ testing.
> I think your interpretation in this context is - at least - uncharitable.
My interpretation is based solely on the words used in the exchange. Charity has no role.
Lastly, charity has a role in any conversation - particularly those involving disagreement. If your conversation partner might be saying something stupid or something reasonable, taking the reasonable interpretation or checking what they meant produces better conversation. I myself would sometimes do well to remember that, in the heat of discussion.
When you post like this, do you ever stop to think how you're making psychology and its supporters look?
http://en.wikipedia.org/wiki/The_Mismeasure_of_Man#Awards
Quote: "The first edition of The Mismeasure of Man won the non-fiction award from the National Book Critics Circle; the Outstanding Book Award for 1983 from the American Educational Research Association; the Italian translation was awarded the Iglesias prize in 1991; and in 1998, the Modern Library ranked it as the 24th-best non-fiction book of all time.[10] In December 2006, Discover magazine ranked The Mismeasure of Man as the 17th-greatest science book of all time."
If self-reference were a disease, you would be in an emergency room. You know nothing about me or the research I have conducted, apart from the fact that your argument represents an all-too-common logical error.
> the opinions of ignorant journalists are not really relevant.
> it was strongly criticized by experts in the relevant area.
So, which is it? Did journalists decide, or did experts decide? And do you know why neither of those sources carry weight in science, a field where evidence trumps eminence?
Do you know why I'm playing you along, even though you have nothing to contribute to this discussion? I just want the readers in this forum to see what passes for reasoning among psychologists and their supporters.
I don't need to. The director of the NIMH already agrees with me, and high-level policy changes are under way to permanently change the status of psychiatry and psychology, demote them to the status of astrology. Didn't you get the memo?
http://www.newyorker.com/online/blogs/elements/2013/05/the-s...
> ... anyone who cares to look will find a vast psychometric literature that supports the validity of IQ.
Yes, that works for people suffering from a bad case of confirmation bias, and who can't grasp basic scientific principles. The rest of us will continue practicing science and advocating in favor of neuroscience as psychology's obvious replacement.
IQ testing will become valid only when it is based on science rather than anecdote. Assuming that ever happens.
The link above by defens is a legitimate criticism of The Mismeasure of Man and is well worth reading. It doesn't speak to the overarching theme of the book, which is it's attack on the goals and the content of intelligence testing, but to a mischaracterization that Gould made of the conclusions of someone else's research, turning them into a bit of a straw man representing subconscious testing bias. It definitely weakens Gould's case in that regard.
The book is still an amazing hidden history.
I agree completely -- the Gould book was an important contribution to the debate about IQ testing, and it contained a number of errors. Both of the above statements are true -- indeed, it's rare for such an important work of this scope to be error-free.
It's my hope that, as psychology is replaced by neuroscience (a process now under way), the role of opinions will be substantially replaced by scientific evidence, which until now has been in deplorably short supply in this field.
In the future, note that calling someone a "noted fraud and liar" is a very serious claim, and you should think carefully about who you level it against. It's powerful language, but used against the wrong person, will make you look silly, and not them.
Look at this gem:
http://scholar.google.co.uk/citations?user=kALUT54AAAAJ&hl=e....
When you're working on teams, under managers, within organizations, you're working to build something that's useful for other people. One of those other people may, coincidentally, be you, but you are not the only such person. Even more importantly, you're working to produce code that can be understood by other people. But that doesn't require an IQ 3 standard deviations above anything, it requires understanding how the people around you think and how you can put your thoughts in a way that they can understand.
Now I'm not saying that there aren't useless meetings in the world, the world is full of them. And your ultimate conclusion is, like Joe Armstrong's, that the difficult isn't in producing stuff the computer can understand; the complexity lies in the fact that it's for people. However, programming without an understanding of the people who will use your program is like a factory worker whose job is putting a screw in the right place on the car. The work is pointless if the end result isn't a car someone wants to use.
If we could specify software as easily as a single model year of a single car, we could factory work that software and you could just code without worrying about people. But we don't seem to be able to do that, because software is so malleable that we can't resist the innate desire to reshape it constantly.
Anyway, back to the point: yes, the difficult part is the people. But it's also the most important part. Here's a suggestion for avoiding the feeling of wasting time: try to embrace the fact that people are important to the process, and challenge your intellect by trying to understand what those people want and how you can match users' expectations while keeping the overhead for developers to a minimum. It's a hard problem, but once you get your head into it it can be as fun to solve as how to architect an application.
He's talking about work experience and that requires a work environment. Not the semblance of one.
10 years experience would put you at the level of a lead programmer, or an entry-level architect.
A 22 year old with ten years of programming experience has ten years of experience doing what he's been doing. He may have built a Mongo-based sports statistics website for his high school. A 32 year old with ten years of corporate dev may have been creating in-house database utilities for MegaCorp's 20 year old Oracle customer database. He's had ten years of corporate database development experience. Is his experience clearly more suited to a Mongo-based startup selling hats to sports fans because his experience was corporate?
Or is it not a matter of corporate vs non-corporate experience but just how much experience doing which of the things we need someone to do?
Are you not an artist if you've only painted things for your own enjoyment, and never any commissioned worrk?
Art is art, code is code. Art is beautiful, code is clever. They are different.
No, you are not an auto mechanic.
Which in most places is illegal at 11 years, so it comes across to me as resumé padding.
The comment I was replying to didn't say "professional experience," just "programming experience." I was responding to this:
This is why, when I see 22-year-old kids in interviews claiming 10 years of programming experience, that's a negative signal for me
And when you have your first 1,000,000 month you CTO (who i think reported to vint cerf ) nudges you saying this had better be right or we are both of a job.
true that. i said more or less the same thing myself shortly after starting work at a big company. just replace "real" with some variation of "business" or "corporate."
not that there's anything wrong with making money or working at large corporations, but just like a 12-year-old might not have any idea what corporate experience is, someone who learned to program at school doesn't know what the experience of mowing lawns in order to buy a compiler is like for kid.
Programming jobs in software business definitely do include many where you can greatly influence the problems you work on and tools you use.
Maybe your applicants were looking for that kind of place (as would many on HN).
Problem being, those efforts essentially make one programmer indistinguishable from another by putting shackles on everyone. I admit there's a certain logic to it, building a business that's dependent on one person's talent can be dangerous. Better to make people interchangable.
All the same: Can you imagine John Carmack writing Doom back in the 90s having to deal with what most coders have to deal with nowadays (With all the "agile")? "No sorry John, you can't commit your highly inventive code without a proper story. We're going to need to have a planning meeting on this and size up story points. Please take a defect off the list. We don't need any heroes or cowboy coders."
I mean, there are overly ambitious programmers that do have to be reigned in, there are people held back by whatever structure you might and many variations of this.
And code has to be appropriate for it's purpose. I'm sure the code for Doom is great for Doom. If it is "cowboy code", it's probably not what anyone would want for an inventory control program that will be passed to someone else in six months.
Yet works of greatness are almost never predictable. You can't reign it into story points or whatever. There's too many false starts, or sudden insights. It certainly takes process and discipline, but not necessarily the kind that can be measured and reported.
That's probably fine for most business, because your inventory control program doesn't need any individual brilliance; but I think it can be frustrating for really good programmers because they do want to create a work of greatness.
Actually, most great artists work with a lot of constraints. There are many great realist painters who accept the constraint of realistically representing the world. Any programmer works with the constraints of the machine.
And working in the constraints of project management and multiple-person provides plenty of room for creativity I would say. Yes, you have the constraint of the code working and you have the constraint of the code being understandable. You might even have the constraint of telling the other programmers how to do the difficult thing you can do and they can't. Greatness is possible there given that greatness is possible with code that compiles as opposed to code which is merely unpredictable.
And project managers are always happy to have people finish faster than expected.
What sort of programming do you do?
It took you 25 years to get where you're right now, does that mean programming is easy? It's the total opposite. In most professions you're ready after 4 years of training, in contrast programming not really.
I don't know how old you are, definitely older than me, but I really hope you don't tell those things you just commented to "the people" you work with.
It wouldn't be if I had just gone on writing orbital mechanics software in Fortran decade after decade, getting more automatic with each passing year, but that's not what "programming" means to me. Every decade or so there is a sea change: corporate mainframes > personal computers > database-backed websites > online economy > mobile > ?
Within each paradigm, there are new platforms with new languages, APIs, libraries, and tools that matter. Yes, I learned years ago how to manually lay out the logic for looping and branching and recursing and callbacking. Like manual-focus Nikon lenses, they're all still useful today.
But it's maddening that the advanced skills that give me leverage in one era are built into the APIs, libraries, and frameworks of the next and no longer give me any advantage. It's maddening that no matter how much I learn, every new team seems full of people half my age who know far more than I do about the tech stack we're using, and I have to wait for the next technology pivot (sometimes more than a year!) to obsolete their advantage and reset the game yet again.
Having to rebuild your skillset over and over is both a technical and emotional challenge that makes software development ("programming" in the real world) hard.