Slashdot Mirror
What Are the Genuinely Useful Ideas In Programming?
Hugh Pickens DOT Com writes "Computer Scientist Daniel Lemire has had an interesting discussion going on at his site about the ideas in software that are universally recognized as useful. 'Let me put it this way: if you were to meet a master of software programming, what are you absolutely sure he will recommend to a kid who wants to become a programmer?' Lemire's list currently includes structured programming; Unix and its corresponding philosophy; database transactions; the 'relational database;' the graphical user interface; software testing; the most basic data structures (the heap, the hash table, and trees) and a handful of basic algorithms such as quicksort; public-key encryption and cryptographic hashing; high-level programming and typing; and version control. 'Maybe you feel that functional and object-oriented programming are essential. Maybe you think that I should include complexity analysis, JavaScript, XML, or garbage collection. One can have endless debates but I am trying to narrow it down to an uncontroversial list.' Inspired by Lemire, Philip Reames has come up with his own list of 'Things every practicing software engineer should aim to know.'"
The "on" button.
Science advances one funeral at a time- Max Planck
if you were to meet a master of software programming, what are you absolutely sure he will recommend to a kid who wants to become a programmer?
Make it clear that 'mastery' of programming involves wisdom and experience beyond knowledge of techniques. My go-to example for this is Code Complete.
are the most useful thing I learned in the last 5 years.
By definition, most programmers are not masters of software programming. So why is Daniel trying to compile a list that everybody will agree with? That would be a list of what every non-master programmer agrees a master programmer should know, which is different than a list of what a programmer should know to be a master programmer...
As for my approach, it would be to list those qualities which would make learning Javascript, XML, relational databases, etc., easy enough to do, by which I mean, those qualities which would allow a programmer to be able to self-teach himself these things, to the master level if his tasks require it. A master programmer doesn't have to know Objective-C or JavaScript, but he sure as heck better be able to learn how to effectively use them if he needs to.
I'm not writing your "How to be a Programmer in 20 Minutes!" ebook for you. You'll have to spend 20 years learning like the rest of us.
Forget about having to learn any specific language or environment. You should be able to pick up any language or environment on the job.
You need to learn how to plan, estimate how long that plan will take to complete, and finish it on time. Very few programmers I've worked with are any good at estimating how much time they will take to complete anything. The worst offenders take double the amount of time they say they will.
Forget about specific computer science trivia. You can look that all up, and it's all available in libraries with various licenses. When you're starting a new job, refresh yourself on how that problem is already being solved. If you need a refresher on a specific computer science concept, take some time and do so.
With this advice you won't burn out at age 25.
What is this, the 90s? In a world with JSON and YAML, why should we bother learning XML for anything other than legacy systems?
People don't know what they want till they see it. Prototype early, prototype often.
To put a witty saying into 120 characters, jst rmv ll th vwls.
the heap, the hash table, and trees
There is nothing basic about these. Each is the subject of on-going research and implementations range from simplistic and poor to fabulously sophisticated.
An important basic data structure? Try a stack.
Yes, a stack. What majority of supposed graduates of whatever programming related education you care to cite are basically ignorant of the importance and qualities of a stack? Some of the simplest processors implement exactly one data structure; a stack, from which all other abstractions must be derived. A stack is what you resort to when you can't piss away cycles and space on ....better.... data structures. Yet that feature prevades essentially all ISAs from the 4004 to every one of our contemporary billion transistor CPUs.
Lurking at the bottom of the gravity well, getting old
"If you push something hard enough, it will fall over"
I think also,
"It goes in, it must come out"
-- Testlcle's deviant to Fudd's law.
"Flyin' in just a sweet place,
Never been known to fail..."
The most useful concept I've ever come across is the notion of a closure in Lisp. The entire operating state of a function is contained within that function. This, and the McCarthy lisp paper (1955!) where it is explained how a lisp interpreter could be created using only a handful of assembly instructions is well worth the read. It is from the fundamental concepts first pioneered in lisp that all object oriented programming paradigms spring; if you can understand and appreciate lisp, the notions of encapsulation, data hiding, abstraction, and privacy will become second nature to you.
Furthermore, if you actually put forth the time to learn lisp, two things will become immediately apparent:
In Stroustroup's "The C++ programming language", there are numerous examples of concise, elegant code. These spring from the concept of deferring the details until they can be deferred no more - the top-down approach results in code which is easily understood, elegant, efficient, robust, and maintainable.
Many years ago, a poster commented that the work necessary to complete a particular project was the equivalent of writing a compiler; he was trying to emphasize just how broken and unmaintainable the code was. The irony in his statement is that most professional projects are far more complex than a compiler needs to be; because he didn't understand how they worked, he thought of them as necessarily complex. However, the operation of a compiler is actually quite simple to someone who understands how they work; the McCarthy paper shows how high level code constructs can be easily broken down into lower-level machine language instructions, and Knuth implements a MIX interpreter in a few pages in the "The Art of Computer Programming." Neither building a compiler nor an interpreter are monumental undertakings if you understand the principles of parsing and code structure. i.e., what does it mean if something is an operator, versus, say, an identifier.
Ideas are powerful; the details, temporarily useful. Learn the ideas.
The society for a thought-free internet welcomes you.
What about code comments? I hated doing it for starters, but when you're working with something big or revisiting code after long period of period, it's invaluable.
As simple as possible to accomplish the task correctly, and no simpler. That and find a career that hasn't been decimated in the last 5 years.
Wait that is what I would tell a kid. An expert would probably preach the methodology he has the most vested interest in.
Exactly. Code Complete is a great book. I liked The Pragmatic Programmer -- from Journeyman to Master even better. It's slightly more meta, but the tips inside are really universa.
Some are even applicable beyond software engineering, e.g. "don't repeat yourself" (i.e. don't have two versions of the same information (e.g. your source in your repository and its documentation on your website) stored in two different places because the probability that over the time both will diverge equals 1. It's better to make one the master copy and derive the other from it.) I recommend this book to all my students.
Computer simulation made easy -- LibGeoDecomp
I think he was missing input validation from his list. The idea that you can never trust user input and you must validate it. The idea that you should white list what you want instead of black list the things you don't want. Ideas that consider the security of the system and not just the working condition of it.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
I would say that one of the most important thing in programming is to break down a problem into parts that are useful and easy to manage. It doesn't matter which language you code in. It's very much like building with Lego - you have more use for all those 4x2 bricks than any other brick. The humongous large bricks are "use once". A right sized brick can be copied and pasted into future code as well, possibly tweaked a bit to suit the new environment. In the process of breaking down a problem - define interfaces. Make a design of the important interfaces to make sure that they can remain stable over time. That can make maintenance easier.
The second most important thing is to learn what compiler warnings means and how to fix them. In this case strong typing isn't your enemy - it's your friend since it will tell you about problems even before you get them when executing the code.
Third is to learn about which known algorithms that are out in the wild so you don't have to invent them yourself. Quicksort is already implemented a thousand times, so there's no need to implement it again, just find which library you need. If you are developing a commercial app you shall start with the Apache project since that license is permissive when it comes to how the libraries may be incorporated. The LGPL is also good. But leave the license headaches to someone else to sort out if you aren't sure.
These are the useful ideas I try to follow, the rest is just a mixture of ingredients and seasoning to get something running.
Remember: You can build a great machine with simple stuff or a stupid machine with expensive stuff.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I'm all for CI (hudson/jenkins being my prefered tool of choice), but no feature branches? Lunacy!
I strongly believe integration has to be balanced. Sometimes people have to be able to run on their own for a bit then merge their work back in. Every commit going straight into trunk and expected to work is going to add lots of overhead and kill momentum.
Most programming confusion I've had to combat in the workplace comes from a fundamental misunderstanding of the two most basic facts of your program:
1. Where is your program's state stored? (NOTE: 90% of the time it's "the call stack" and 90% of the time that's the wrong place to put it.)
2. Where in your code is execution happening?
Threaded program generating weirdness? It's probably because you can't answer those two questions. Distributed program a mess to debug? I bet your state is smeared all over the place. Is your code a pain to port to an evented architecture? Bet you modeled your state badly. Can't map some failure to a certain, detectable set of circumstances? I guarantee your answer starts there.
For me, the answer to understanding these problems was found in functional programming. The no-side-effects stuff causes you to make all of your state concrete and also deeply understand what the call-stack does for you (or, more often than not, *to* you). The cruel reality, though, is that applying this hard-won knowledge *doesn't* seem lie in functional programming (or, at least, not LISP, Schema, Haskell, and crew).
If you're an academic, start with Hoare's Communicating Sequential Processes (http://www.usingcsp.com/cspbook.pdf), then learn Erlang (or Go, with a heavy emphasis on GoRoutines). If you're less Ivory Tower, try to grok this blog entry (http://blog.incubaid.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/), then learn Erlang (or Go, with a heavy emphasis on GoRoutines).
I think Mauve has the most RAM. --PHB (Dilbert Comic)
EOM
... are too specific. The concept of an Atomic Operation is important; database transactions are just a domain-specific example.
Surely any programmer ought to know the underlying principles that make databases work (ie ACID etc) even if they never intend to go anywhere near multi threading. Even in single threaded programs knowing what and how ACID works can help. Have you never done a write() and wondered where the data you sent to disk went?
Perhaps the relational calculus might not be strictly necessary, however if knowing the theory behind relations helps engineers from naively treating databases as data garbage dumps, it'd be worth it.
Plan My Week for iPhone
The most important book I read as a beginning software developer was Software Tools in Pascal. That book teaches a technique it calls "left-corner design". It's kind of a rule-of-thumb for how to do agile development informally.
The basic idea: pick some part of the task that is both basic and essential, and implement that. Get it working, and test it to make sure it works. Now, pick another part of the task, and implement as above; continue iterating until you either have met all the specs or are out of time.
If you meet all the specs, great! If you are out of time, you at least have something working. The book says something like "80% of the problem solved now is usually better than 100% of the problem solved later."
For example, if you are tasked with writing a sorting program, first make it sort using some sort of sane default (such as simply sorting by code points). Next add options (for example, being able to specify a locale sort order, case-insensitive sorting, removing duplicate lines, pulling from multiple input files, etc.). A really full-featured sorting program will have lots of options, but even a trivial one that just sorts a single way is better than nothing.
Also, the book recommends releasing early and often. If you have "customers" you let them look at it as early as possible; their feedback may warn you that your design has fatal flaws, or they may suggest features that nobody had thought of when imagining how the software should work. I have experienced this, and it's really cool when you get into a feedback loop with your customer(s), and the software just gets better and better.
Way back in high school, I tried to write a program to solve a physics problem. I hadn't heard of "left-corner design" and I didn't independently invent it. I spent a lot of time working on unessential features, and when I ran out of time I didn't have a program that did really anything useful.
This is the one thing I would most wish to tell a new software developer. Left-corner design.
P.S. Software Tools in Pascal is a rewrite of an older book, Software Tools, where the programs were written in a language called RATFOR. Later I found a copy of Software Tools and found it interesting what things were easier to write in Pascal vs. what things were easier in RATFOR... and when I thought about it I realized that everything was just easier in C. C really is the king of the "Third-Generation" languages.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I don't know if that's really good advice anymore.
I mean if it's an interest, sure. Personally I love that stuff.. but unless you plan on doing low level coding for a career, modern programming is so abstract from machine language that knowing what's going on down there is in most cases interesting trivia at best.
Learn to manipulate text and you can do just about anything.
When it was part of our CS required curriculum, I suspected I would never use it, but it turns out that the vast majority of projects I've been involved with have used databases in some way, and one of them even involved some pretty serious database query optimization. As far as I can tell, unless you pretty much code exclusively down at the kernel level, you're going to eventually be asked to work on some project involving databases. They're the glue that holds technology together. Outside of a handful of niche fields, I'd be surprised if any programmer managed to go more than five years out of school without having to work with one.
Also, once you understand databases conceptually, everything starts to look like a special case of a database. This is a good thing. C data structures? Table records. Pointers? Relations. And so on. It ends up helping you understand complex problems even if you're one of those rare people who never ends up touching an actual database.
Check out my sci-fi/humor trilogy at PatriotsBooks.
1) Learn how to have fun. Even when you're mired knee-deep in a gigantic pile of horseshit that is a 10-15 year old VBA/Access/Excel monstrosity written by a half dozen people and commented occasionally in non-english languages, if you can't find a way to enjoy the challenge, your career will be short-lived and miserable.
2) Work on things that interest you. When you invariably get the point to where you think "I wonder if there's an easier way to do this", google it. Chances are, you're right. With any luck, you can avoid #1 above if you really work at it. I don't think anyone ever woke up in the morning thinking "Fuck this fun shit, I want to be a Programmer III at some .gov contractor", but you never know. I happen to like maintaining and bug-fixing code more than I do architecting full solutions, but I'll accept that I'm an odd bug.
I mean, I'm reading some of these comments and thinking "yeah, if you pushed Knuth or SICP on me when I was 10, you'd have killed any interest I had in computers." Instead, I was POKEing away on my C64, etc. If anything, figuring out how to solve logic puzzles, breaking down problems, etc, were much more fun for me in the 5th and 6th grade than reading some of the current compsci literature that I *still* require significant motivation to go through. I'm not saying it's not important, I'm just saying that a middle schooler (a kid) may not be all that willing to put in that kind of work, and waiting until college wouldn't be so bad. You know, going back to the comment thing.. a lot of these comments sound like the anti-jock jocks. I remember these kids who's parents were forcing them to play sports and everything revolved around these kids playing sports, but the kids themselves weren't having any fun at all. Now we have nerds acting like jock parents, treating their kids in the same manner.. It can't be healthy.
If you were me, you'd be good lookin'. - six string samurai
Cybernetics. Information Theory. Done. Everything else in the Universe can be mastered & described with these, even physics and quantum physics.
I taught my 12 year old cousin how to build an adder circuit using a neural net visualization simulation. Then we built it IRL with contractors, then transistors, then we cheated and used some pre-made ICs. He "invented" the Von Neumann architecture by him self -- Well, I should say it was self evident given the core concepts of cybernetics and information theory. He was excited as ever to learn assembly languages and higher level languages, marveling at the heights everyone has gotten to from those core principals. There is no system or language he can not now understand. Even encryption systems he can grok using Information Theory / Entropy.
I really couldn't imagine introducing anyone to even higher mathematics without giving them the tools to apply and visualize it first... I mean, Turing gave us a universal calculator and we still teach times tables first?
Half of those things are NOT things I would "recommend to a kid who wants to become a programmer".
Version control, UNIX philosophy, software testing - it's too much! Someone who wants to be a programmer should start to learn programming first, and then they can explore the wild twists and ideas that surround the thing once they have a grasp of what programing means to them.
I would say even starting languages to recommend depend on the person. If a programmer likes some languages and not others later in life, why should that not be true from day one because of how they like to think? What if you are recommending a language that will turn them off programming forever?
It would almost be best to develop a kind of programming sandbox, that would let them use a variety of languages and concepts (like functional or OO or even, yes, procedural!) and see the path they take most naturally.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
My introduction to programming went something like this: I started with a small home computer, pre-IBM-PC. It came with Interpreted BASIC. Lucky me, Consumer Reports recommended that particular computer above the others for 2 years, because the manual, teaching BASIC, was very engaging. But let's back up a bit. A few years before computers started getting into homes, a Logic Game hit the market ("Master Mind") and received a Game Of The Year award. That game made it fun to practice Logic. Computer programming relies a great deal on thinking logically, so practicing Logic is very important --but having fun practicing Logic is better still. Later, I jumped from BASIC into Assembly Language Programming --and once again I was lucky. Not only was the processor of that home computer designed to to make programming it easy, the Book I got on how to do that was among the best in the field. So, what sorts of programs did I write? Games, of course! They can incorporate all the important features of any other application; User Interface, Visual (and sometimes also Audio) Outputs, Data Storage/Retrieval, Occasional Oddball Hardware Manipulation, Algorithms. And, of course, the more-developed a game-under-construction became, the more fun it was to test/play. We All Learn Best By Doing. Later, when I began doing professional work, and it wasn't always fun, I could still "hold my own" because the foundations of that career had been solidly emplaced.
"Quicksort is already implemented a thousand times, so there's no need to implement it again, just find which library you need."
Yes, that's true, but we're talking about education here, not building websites.
If you're a coder, and you don't know how to BUILD a hash table from genuinely fundamental, low-level components, or if you can't do a quicksort from those same fundamental building blocks, guess what? I won't hire you.
It's great to be able to buy or borrow a used V8, but if you don't know how to build one, you're not going to be my mechanic.
The single most important thing isn't about software engineering specifically, it's the ability to analyze a problem, break it down into it's component parts and work out a structure for your solution that solves the problem well. Just like the most important part of building a house isn't anything to do with actually building it, it's deciding what kind of house you're going to build, what rooms it's going to need and how they're going to be arranged. You need a very different house if you want it to support a family with 2 or 3 kids vs. just a single person or a couple without children. If you don't get that right, all the technical chops in the world later on won't help your having been hamstrung by a bad overall design. Lack of that ability has been the root cause behind something like 75% of the "software engineering" failures I've had to deal with.
IMO, a function should be as long as it needs to be, and no shorter or longer. If the most easily understood way to express a concept is as a 5,000 line function, then you should write a 5,000 line function. Splitting up a function based on some arbitrary length limitation can only lead to less readable code.
For example, my record is almost 5,500 lines. The entire function is basically a giant switch statement in a parser (post-tokenization). The only way you could make that function significantly shorter would be to shove each case into a function, and all that would do is make it harder to follow the program flow through the function for no good reason. At any given moment, you're still going to be staring at exactly one of those cases per token (plus a little code on either end), so having each case in a separate function just adds execution overhead without improving readability, and it makes debugging harder because you now have to pass piles of flags around everywhere instead of just using a local variable.
One of the data structures for the function in question is almost 1200 lines long by itself (including anywhere from two to fifteen lines of explanation per field, because I wanted to make sure this code is actually maintainable). By itself, the initializer for that data structure cannot meet your "fits on one screen" rule, even with most of the fields auto-initialized to empty. And there's no good way to shrink that data structure. It is a state object for a very complex state machine. The code to interpret the end state is over a thousand lines of code by itself.
In short, those sorts of rules simply don't make sense once the problem you're trying to solve becomes sufficiently complex. They're useful as guidelines for people who don't know how to write code yet—to help them avoid making obscenely complex functions when the functionality is reasonably separable into smaller, interestingly reusable components, to keep themselves from shooting themselves in the foot by repeating code where they should call a shared function, and so on. However, IMO, if you're still thinking about rules by a few years out of school, they're probably doing you more harm than good, causing you to write code with unnecessary layers of abstraction for the sake of abstraction.
Check out my sci-fi/humor trilogy at PatriotsBooks.
You would be surprised how many delusional, idiot developers are out there.
There's a great future in encryption. Think about it. Will you think about it?
You're probably not qualified to think about. It's hard. Really hard. And very specialized.
No new cypher is worth looking at unless it comes from someone who has broken a very hard one. - Friedman
I would much rather my mechanic focus his efforts on being good at diagnosing problems and installing factory-made parts rather than troubling himself with building parts himself. I feel the same way about programmers. The simple components (like sorting algorithms) are largely available in libraries, and I would be more concerned that someone I work with know when to use a particular sorting algorithm than that he/she can code up one from scratch.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Sarcasm aside, it's a useful algorithm that beginners can easily understand. With the right prompts, they can even "invent" it themselves.
Required reading for internet skeptics
"Find me a mechanic that can build a V8."
I didn't write manufacture a V8 from scratch, I wrote "build".
I rebuilt an engine, and I'm very far from an auto mechanic. And in the interest of keeping the record straight, I had help and advice. But that's my point here: I wrote "build", not "design and manufacture all the parts from scratch". It's all fine to get help and advice for coding, too. But I wasn't suggesting trying to independently re-invent internal combustion or anything like that.
"I agree with the anon poster. You are an idiot. A computer scientist better be able to write a QS in their sleep, but a programmer better know how to find a suitable implementation already written."
That's not a programmer, that's a hack just out of high school. There IS a big difference, and if you don't know what that difference is, you're paying too much money.
Now tell me again who's the idiot.
I wasn't suggesting that every programmer has to know how to do finite-elelement modeling, for fuck's sake. But if you don't know a Quicksort from a Bubble sort, or how to write them, you're not a programmer by any standard I ever heard of, and I've been around.
"Sometimes you need more than a mass-produced transport designed to a price for the lowest common denominator."
Agreed. Just as engine mechanics fix engines -- for FAR less cost than simply buying a new one -- if you have a coder who actually knows how to code, maybe he or she can FIX a problem, rather than re-writing your whole application from scratch.
In some ways this is even more important than in the engine mechanic analogy, because your software likely WAS written from scratch. So it's a hell of a lot cheaper to hire a code "mechanic" who knows what she's doing to fix it, than it is to do it all over again from the ground up.
Hey, thanks for the heads-up, because I don't want to work for you. I CAN jump through hoops, but I'm a couple of decades past the days when I was WILLING to do so.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
"Good software development is to a chemist As lego development is to a cook."
Well, I have to tell you honestly: I don't know whether that went over my head, or under.
But either way, it missed me completely.
Hands down, the most important idea in programming. See the C++ disaster for proof.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Until you've programmed ASM for a micro controller, you really don't know what's going on under the hood, and you're almost certainly doomed to create bloated, slow-as-mud compared to what it *could* be, code.
Sit down with a 6809 system emulation and learn about stacks and heaps and PIC and addressing modes and registers and memory and IO and optimizing loops and etc. Then you've got a foundation. Then C and a linker AND a debugger, then something OO, then HTML, CSS, Python, PostgreSQL, follow the basic PostgreSQL with detailed DB stuff, make sure the math is there through at least algebra and geometry, explain 3D from acos() as pooltable reflection to the various lighting tech... this would be a good first year or possibly two.
You best learn to solve problems by... wait for it... solving problems.
I've fallen off your lawn, and I can't get up.
"1. Don't use proven libraries to solve common programming tasks (e.g., collections).
2. Write everything from scratch!
3. Argue that it is a time and budget advantage to do so."
No. That wasn't the point of this discussion at all.
I highly recommend that programmers DO use proven libraries to solve common tasks. BUT, a programmer who is worth a real programmer's salary COULD write them herself if she had to, which means she also has the skill to identify and preferably fix bugs in said libraries. After all... open source software is all bug-free, yes? (Not that it has to be open source... just an example.)
I wasn't saying a programmer should write everything from scratch every day. But if you don't know how to, you're SOL and at everybody else's mercy when something goes wrong. You're costing your company money. Because things go wrong.
Better list:
I wanted it to be 10 but that's all I could come up with, that I would recommend any programmer, new or not.
I've heard lots of good things about it. I just haven't heard anything about it that's unique to OOP. Hell, no one can even agree about what constitutes OOP!
I'd ask you to defend it, but you'll just mumble something ridiculous about "modularity" and I'll be forced to laugh at you.
Required reading for internet skeptics
I'd be interested to know what line of work you do, programming wise. My experience tells me that a lot of programming that is being done is meant to be powerful and meant to be built quickly. Running quickly and with low tolerance for faults is a little less important because very few things are mission critical. While anathema to the academic, it demands a certain skill set, which is the ability to very quickly assimilate new arbitrary knowledge about libraries, software, and code, that the programmer hasn't seen before. The result is a fragile sort of knowledge that often lacks formality and granularity but is sufficient enough to accomplish a task very quickly.
This skill is not exclusive with the ability to write everything from scratch, but understanding a system through and through seems to often undermine the coder's speed at getting the product out because they want to do it 'correctly'. This specific tug of war, between programmatic idealism and pure ease of use often ends up being a major concern in the work I do because I am rarely satisfied with the 'easy' solution. Sure, sometimes doing it 'correctly' amortizes quickly and thus the up front cost should be paid, but other times it really just badly trades one resource (dev time) for another (execution time, time of the humans managing the software, time to market).
I've met coders who talk like you, and when they do, they're so impractical in their overarching decisions that often the software is DOA because it doesn't do enough, or it took too long to write, or it was endlessly being refactored.
You're probably doing work at a more basic systems level than I am. And, maybe that is why you have this philosophy. I used to think work at the level I'm doing now was uninteresting, but the problems are shifted into ones of integration, forward planning, and multi-discipline and away from algorithm, pure transaction, etc. There are also a buttload of programmers working at this level, and while I would love to say that we must hire only candidates who can write a minheap backed up by a btree... I think by far the more important qualification is that skill I was talking about, which is a lack of 'not invented here' syndrome and an ability to read other people's code / technical documentation very quickly and see how their architecture can fit into our needs with the minimal of fuss.
To put it another way, most of the low level problems have been solved adequately enough for this level of work, but there are a whole slew of emergent problems that require more than just Pattern A + Pattern B to solve, and are just not that helped by understanding the machine instructions or by algorithmic knowledge. I believe that to be true for probably the many of the programmers that are gainfully employed. So, I could not agree with the notion that your hiring strategy would work well for most positions.
Or go for Go. Almost like C, but better suited for anything with more than one CPU core, and without certain awful syntactic baggage.
Ezekiel 23:20
And that's exactly why my DVD player takes 30 seconds to start up while a 30 year old vcr would start playing pretty much right away. Just throw some libraries together that do what you want to do, including the libraries required by those libraries, and finally including an entire linux or other OS because, well, otherwise you can't use those libraries. I wouldn't be surprised if the thing had a hypervisor and multiple OSes too.
Programmers nowadays just bandaid lots of existing stuff together without knowing how it all works. The result is bloated software that requires gigabytes of memory while the same stuff used to work just fine on a 64k 8-bit computer.
Can you remember how much stuff used to get done by applications using 64k of memory? And how much memory those same applications would gobble up if they were written today? That's the price of throwing libraries together instead of actually programming.
That doesn't mean you actually have to write everything from scratch, you certainly should try to reuse existing code and libraries wherever possible, but you should also know how they work, what they do, and whether or not they are overkill for what you're trying to do.
If you ask today's "programmers" to provide an engine for a kitchen blender, they'll use a V8 truck (not the engine of the truck, but the entire truck) and connect the blender to the wheels of the truck somehow. Being able to take the engine out of the truck would be a big improvement already.
Some people actually provide documentation with their code? Your point highlights the importance of quality documentation that allows an outsider to quickly understand a code base. Something quite useful in the open source world.
"All problems in computer science can be solved by another level of indirection"
(David Wheeler)
So true....
Oh I totally get you on clearcase. It's one of those tools that people often succeed not because of, but inspite of.
As to the origional argument, as someone said below, it comes down to scale and what's best for the specific project. Most of my career has been spent on large projects with many developers and in some cases multiple integration trunks, so I'm kinda skewed to the mindset that committing to trunk == ready and tested by developer. Everyone committing partially complete and untested work to trunk would be a complete mess.
That said I try to maintain the pragmatic view that if something is working and causing no problems, it's probably not wrong, regardless of what best practices and conventions say. If what you are doing is working at whatever scale you operate at, and you don't believe branches would enable you to work better in your workflow, then it's the right choice!
That's pretty much the workflow I've seen most of my career. The big failing is when two people are working on large feature branches in the same area, but that can be mitigated by good project management (having two people working on different major changes in the same area is usually a terrible idea imo).
It's always usually possible to do a custom integration build for really big stuff (trunk + your branch(es)) and run the full test suite.
But if you don't know a Quicksort from a Bubble sort, or how to write them, you're not a programmer by any standard I ever heard of, and I've been around.
I have been a professional developer for the past 10 to 15 years and have not had to write a sorting algorithm in almost 2 decades (since college, at least 15 years ago). I dare say I could write one pretty quickly if asked, but it would be a much more efficient use of my time to just google for one since there are tons of them out there without any licence restrictions. What I could do though is understand every line of what I found at a glance and easily make any subtle changes needed to drop it into what ever project I was working on.
Writing this sort of basic stuff is a useful educational tool since the model answer is pretty well established, but you very rarely have to rewrite the same previously solved tasks once you are getting paid for your time.
I dont read
"Quicksort is already implemented a thousand times, so there's no need to implement it again, just find which library you need."
Yes, that's true, but we're talking about education here, not building websites.
Also, knowing about QS implementations lets you know when it's been done wrong.
Case in point: Microsoft's C runtime library shipped around the time of Windows NT and Visual Studio 6 had a sub-optimal qsort implementation - it took 97 seconds (on a 600MHz Athlon) to sort 260,000 integers with a constrained set of values (0-180), whereas other implementations (eg Numerical Recipes) could do it three orders of magnitude quicker.
Delving in, the qsort() algorithm didn't exchange elements where the value equalled the partitioning element, which leads to increased comparison function calls (effectively proportional to 1/range).
"Right - but if I catch a programmer ever actually implementing a quicksort by themselves though, they're fired."
Well, I won't argue with that. As I stated earlier, I don't think one should spend every day re-inventing the wheel. But knowing how to make a wheel if you have to is a valuable skill.
"I dare say I could write one pretty quickly if asked, but it would be a much more efficient use of my time to just google for one since there are tons of them out there without any licence restrictions. "
Please read what I wrote a bit more carefully. I did not write that I think you should be writing such things on a daily basis. And I certainly don't recommend it. But you should be able to, should the need arise.
"I've met coders who talk like you, and when they do, they're so impractical in their overarching decisions that often the software is DOA because it doesn't do enough, or it took too long to write, or it was endlessly being refactored."
Who talk like me? It's funny, because I'm not even disagreeing with most of what you say. But a quicksort is not rocket science, and anybody who studied programming or CS in college has been exposed to how they work. If they have any schooling behind them with significantly more depth that PHP scripting, they were probably also exposed to how hash tables are contstructed.
Why is it arrogant to insist that they remember some of the most basic things they learned? If I were to hire a mechanical engineer I'd want to be sure he knows trigonometry.
But if you're talking about some guy pounding rivets, well, he's not an engineer. He's a hack laborer, and he probably doesn't need to remember his trigonometry. And that's exactly the difference I was talking about.
"There is absolutely no reason to have the various sorts memorized, no matter what you do for a living."
THAT is absurd. Seriously.
"Not once have I ever needed to write a sorting function or try to remember the differences in implementation of the different sort algorithms. It just isn't important."
And I'd be willing to bet that the fact that you don't even remember something so ridiculously simple and fundamental has a direct relationship to the quality of your code.
It's only a guess and I could be wrong. But if I were to bet on it, that's they way I'd bet.