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.
I'm talking about two points here:
1. The tools: have a CI server to do automatic validation.
2. The concept: try to integrate early, integrate often. Your automatic validation will catch errors and you'll be able to solve them quickly. If you wait a long time to integrate, you will just have a huge bunch of stuff to integrate, and possibly too many errors.
The second point is why I prefer not using feature branches in version control (and yes, I use DVCS).
Problem solving.
The ability to think through how to put pieces together to solve a problem.
Without this ability, nothing else is useable.
McLae
are the most useful thing I learned in the last 5 years.
Structure and Interpretation of Computer Programs
https://www.youtube.com/watch?v=GAHA0nJv8EA
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.
The two duct tape equivalents for IT.
"Indirection can solve any problem in software, except for too many layers of indirection."
- Anonymous
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.
No? Then keep hacking.
That's all you need to know in order to learn programming.
database transactions; the 'relational database; ... I am trying to narrow it down to an uncontroversial list
Well he's already failed. Databases are a niche topic that doesn't belong in an "uncontroversial" list of things that every software engineer needs to know.
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.
Clean Coding
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
Learn an assembly language. Program hardware. Learn what goes under the hood.
OP sounds like something a cis major would go on about to impress people. And asking implies you think we're "master programmers", and are really asking our opinion while playing on hubris.
But for the sake of pretending, I'd first breifly explain the turing machine, that it can calculate any possible computer program, then introduce them to python. After that, they can explore to fill in the gaps. No one likes to be lectured, especially not new programmers.
Some stuff I would probably add:
Basic understanding of caching/Virtual memory and the concept of temporal and spatial locality
Ability to write/read simple examples of RISC-style assembly (MIPS, etc.), in order to understand what exactly it is that a compiler outputs
Passing by reference vs. Passing by value.
Software componentization.
I'll use a generic term here, whether the specific implementation at hand is via OOP, a defined API to a DLL, a web service, or any of myriad other concrete forms.
The list as presented is indeed core to being able to develop an application up to a certain level of complexity, and in a learning framework where one can conceivably be able to, and can be expected to, understand or visualize the entirely of the project.
Beyond that level of complexity, though, the notion of being able to efficiently deal with software functionality as a "black box" for which the developer need not know all the particulars of implementation, allows for the allocation of mental resources to the particular requirements of the task at hand. Being able to use others' code in this manner, and write code in this manner, is to my mind a crucial ability to contribute to an actual professional development team.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
GUI programming is a new thing and still it's rapidly transforming. Change that to event-driven application architecture, which almost all GUI apps have.
Relational databases, well... NoSQL would be enough for this list.
Model-view stuff seems to be missing from the list, and all kinds of patterns in general. Also, totally missing from TFS is client-server models, be it the backend-frontend model of web apps, or traditional TCP/IP protocols.
That being said, if you master every aspect of Qt5 including QML and using network and databases, and development for different mobile devices, while also embracing the functional aspect of JavaScript (for QML and HTML), you should be pretty well set for everything on every platform ;-)
Any discipline that can list its core ideas in a short Slashdot post isn't worth studying.
You know rules of thumb like "NO, YOUR FUNCTION SHOULDN"T BE 5000 FUCKING LINES LONG. IT SHOULD FIT ON THE GOD DAMN SCREEN." or "KNOCK IT OFF STUPID. YOU SHOULD HAVE WROTE ONE FUNCTION TO DO THAT. NOT CUT AND PASTE THOSE 10 LINES OF CODE 70 TO 80 TIMES." (Before anyone asks, yes I've literally seen programmers, software engineers, or whatever we're calling them with years of experience make amateurish blunders such as the above. And yes, they really did do those 2.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
"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..."
He lists quicksort as more useful than OOP? Quicksort is cool, but.......
I'm a C programmer, so I understand people who say OOP isn't everything, but the concepts you learn with OOP are a whole lot useful than the concepts behind quicksort. You even use those concepts when you use a language like C. It could be argued that learning algorithmic complexity is more important than OOP, but that is a different than learning quicksort.
"First they came for the slanderers and i said nothing."
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.
I'm the best programmer on the planet. That's why God chose me for His temple.
I took 5 asm courses, a compiler course and operating system course. Meat and potatoes.
I learned to read datasheets. I studied digital design. I am expert on boundary between hardware and software. Plus all my job experience.
I was a professional OS developer at age 20 on Ticektsmeter's VAX os in VAX asm. I was paid for x86 asm, 8051 asm projects, 68000 asm projects, PIC asm projects, atmel acr asm projects. I am a master of bare metal asm programming interacting with hardware with no operating system.
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.
Getcha a really nice GREP tool of some sort where you can search through source code easily and do replacements when necessary. I use mind all the time. Comes in quite handy when you're working on code written by other developers.
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.
Seek to understand the various levels of abstraction available in any problem -- and to solve the problem at the appropriate level. It's a complicated lesson, and something that will take a long time to get right, but once you do, so many things fall out naturally, like clean and reusable code, the need for different languages and tools, design patterns, and on and on and on.
"You know, Hobbes, some days even my lucky rocketship underpants don't help" -- Calvin
If there's one thing I've found most useful in developing software, designing computer systems (or any system, for that matter), is to develop a keen sense of pattern recognition.
For low level that missing (at least from the summery: arrays, caches, and concurrency.
For higher level: abstraction, interfaces and algorithms. (Why cover quicksort if you don't include the concept of having an algorithm, with an interface that provides an abstraction?)
Some of my other favorites: Idempotentcy, stateless vs stateful, mutability, policy vs implementation, lazy vs eager, protocols (as a concept), cache-oblivious algorithms.
Also: higher order functions, dynamic dispatch, polymorphism.
Lastly, screw teaching quick sort. Tim sort show something very important in software engineering: hide your optimizations behind a good abstraction, because they make one hell of a mess.
If you're not sure if you want to use a pointer driven data structure or an array, favor the array. In languages like C++, when you use pointers, you can deference it and your code will work perfectly for the time being. So when you're doing your standard debug cycles of checking your code for errors, these can pass by, and not be seen again for days or weeks. A dereferenced pointer can end up causing your code to crash abruptly over completely arbitrary things. The only way to debug this is to read through your entire code base. I also suggest prayer. I find prayer works.
Anyway, if you favor arrays over pointer driven data structures, you simply won't blow your leg off as they say in C++. Your errors will be easier to track down. You have a lot less chance of encountering a bug that you can't easily debug which also crashes your entire program randomly. And finally, you'll become an array master(since you use them so much) so your code will come out faster.
Now some people might disagree with this, but this works for me. Sure there's some times you absolutely need to use a creatively designed linked list, but if you can do it with an array and an unnoticeable slowdown, go for!
God spoke to me
Yes.
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.
There's a great future in encryption. Think about it. Will you think about it?
Beware of charming open source projects via forums and irc rooms. You will be falling into a personality cult.
Become a polymath, you will need history, science, art, music, math and much more to fully understand the needs of your buzzword touting clients.
Beware of the security clearance - years of your life will be dedicated to larger projects with real world stories, the press and politics.
Be aware of who your working for and their reputation. Their global vision, lies and domestic issues will be all over your clean CV for years.
Study your boss the way a team studied your CV. Who is really paying the bills.
Programming languages are like fads, short-lived and very amazing. Learn the educational basics, then see what interests you.
Domestic spying is now "Benign Information Gathering"
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.
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
Understand that every line of code you write may/will be maintained by somebody else. Architect/Design/Write/Test accordingly.
Recursion = Recursion (X-1) + Recursion (X-2)
In the list of concepts, along with OO, closures & functions, recursion is essential knowledge. If in doubt, see this post.
... are too specific. The concept of an Atomic Operation is important; database transactions are just a domain-specific example.
To solve a problem you have to understand it.
An idiot with the best tools in the world will still be bested by a thinking man with only what he needs.
Arrays start at zero and go through size-1.
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
Node may feel too 'advanced' for the absolute beginner, but I would recommend any course mention input/output issues and how the use of callbacks can be so important.
Learn to manipulate text and you can do just about anything.
The behavior of floating-point arithmetic. This wasn't covered in my university curriculum, and was necessary in tasks including graphics, machine learning, and finance once I got into the industrial world.
As a manager, possibly the single most important skill for me was learning the ways to estimate the time required for complex programming tasks. Once you're tackling problems beyond the scope of a single programmer, coordination is required, and schedule estimation is essential.
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?
DOCUMENTATION. whether for yourself later on, other developers, or the oft-neglected end user.
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
These lead into the ideas of computability, complexity and space(memory)/time constraints. All other algorithms can be understood better and their suitability evaluated based on one's understanding of these.
Reflection, as found in .NET allows you to write extremely generic yet powerful code easily. For example, I have used it to write a method that can write any class (or list thereof) to a CSV file of any format by passing in a field-to-value map object along with the object data you want to store. The beauty of this is that you can store the format of the file externally and make changes to it without having to rewrite the code. The only time you would need code changes was if you needed additional properties added to the class you want to write out.
Jesus was a compassionate social conservative who called individuals to sin no more.
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.
Bubble sort. Best idea ever.
The worst you have seen is someone taking twice their estimate. You must be working on some easy problems.
The practical issue is that when solving real problems the work in writing code is 90% design, and since no one has done that before estimating with any accuracy is a pure guessing game. The harder and the more challenging the problem the harder it becomes to give an accurate estimate.
That doesn't mean you can't control your schedule. You can always drop features or build incremental developments and deliver what you have. But giving a precise estimate is nonsense.
In fact I have found that I have gotten better and not worse with age, as the problems I am tackling have gotten harder, and correctness has become more important.
"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.
Reality is defined by what the machine does, not what books say the machine should do.
Yes. Divide and conquer (or structured systems programming), and make your inheritor's life good (good karma). A good compiler is good. Typing is a computer science term--not a reference to pecking at the keyboard. Algorithms is a funky term. Ultimately it is a reference to doing things in discrete mathematics. Mathematicians really do give "it" away. "...the rest is just a mixtures of ingredients...." This is a reference to making things taste good. It's relevant, informative, honest, and a description of doing the right thing. It's a moral attitude. To sum it up for people not in the culture: Do good, engineer, break problems up into their component parts. To lazily invoke a giant, beauty is harmony of parts in a whole (Aristotle somewheres).
You would be surprised how many delusional, idiot developers are out there.
Make it clear that 'mastery' of programming involves wisdom and experience beyond knowledge of techniques. My go-to example for this is Code Complete
Find me a mechanic that can build a V8. They don't have the metallurgy, the physics or the engineering to do it. That was a ridiculous example, and I wouldn't want to work for you.
Amazingly security, secure programming, defensive programming, security testing don't make the list.
Maybe that's why there are so many code vulnerabilities out there.
Andrew Yeomans
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."
No mention of how to make professional installation packages which can be maintained in a production environment.
Really the list is "things every coder should aim to know". Need much more to get the "software engineer" label.
Andrew Yeomans
Couldn't agree more. With respect to algorithms already implemented, there should be a one-stop repository of them with descriptions and variations for different languages. Like Wikipedia but just for algorithms (even painfully simple ones). More than anything else this would benefit all programmers, but especially newer ones. Searching Google for stackoverflow/etc. posts sometimes helps but is often an unnecessary timesink when you have a specific algorithm in mind but don't know what it's "called".
Buy your next Linux PC at eightvirtues.com
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. If I were hiring a programmer (rather than being one), I'd look for people that know what needs doing and how to find code that already does that job. In your typical app, there's very little custom algorithm work. The vast majority is simply tying pieces together to generate the desired outcome.
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.
There is a slight risk with teaching this blindly.
Look at PHP, full of library functions that does what you want but not exactly. The result is a mess of library calls with unnecessary complex glue logic that adapts the data before and after the call.
If you can't find a sort algorithm that fits how you structure your data the best solution might not always be to restructure your data.
I would say that it is just as important to know when to roll your own code as to know when you shouldn't.
I'm never going to pay a mechanic to build me a replacement engine from scratch. So why'd I need a mechanic who'd know that?
That's as stupid as not using doctors because they don't know how to build a brain from scratch...
All I want is a mechanic/doctor who knows how the parts work reasonably well, how they are likely fail and how to fix them for a reasonable price (it's easier to fix something if you have heaps of money, but I don't have heaps of money).
The question didn't call for an overview of the field, I.e. ontology, but a list of Fundamentals. An ontology is useless to a kid.
Heres my list:
- Variables
- Algebra
- Logic
- Functions
- Loops
- Structures and Classes
- Iteration
- Recursion
- Input / Output
Two pieces of software will communicate over some Internet Protocol. If you have no idea how information travel (or not) between two machines, then stop here. Did I mention security too?
"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."
Cool. So when something fails, you can pay them to go find some other pre-built part, and follow the instructions to hopefully make it work.
That's fine, I suppose, if you have the time and the budget. I prefer to simply hire people who know what the hell they're doing.
I'm never going to pay a mechanic to build me a replacement engine from scratch. So why'd I need a mechanic who'd know that?
Sometimes you need more than a mass-produced transport designed to a price for the lowest common denominator.
.
No sig today...
How recently has your hiring strategy worked?
"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.
Data structures, specifically collections. Whenever you have to store more than 1 of something, you have a -lot- of questions to ask yourself before you touch that keyboard. Ordered or unordered? Duplicates allowed or not? Quick lookup via a key or unimportant? Iterating forwards, backwards, or never? Random access and removal, or chucking stuff on the end? Synchronised or unsynchronised? Answer all of these, before deciding whether it's a list, set, map, tree, queue, stack, and what subvariant of those you need. It'll save a -lot- of refactoring.
"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.
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.
Did I just get trolled? fuck
To paraphrase a recently overused example,
Good software development is to a chemist
As lego development is to a cook.
Not that I know much about them
"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.
www.RosettaCode.org
First time I've ever done this, but ... me, too.
One of the most significant things i learnt as a programmer after 20 odd years is that being a good programmer isnt enough, you have be capable of design as well.
Knowing only syntax allows you write functional but unmaintainable code. Knowign only design allows you to beatiful but disfunctional code. You need both.
Nothing worst than having a fairly catastrophic bug (e.g. buffer overflow) that only degrades program performance slightly, but does not lead to obvious misbehavior.
GONG !!
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.
Actually, I have built a quicksort, and several kinds of hash functions and hash tables, from scratch. I've also built a FILE style I/O layer using sockets, an HTTP server, a BSD style NDBM replacement, and most recently, a high speed, memory efficient GUI text scrolling window class. All of these except the GUI module I did before I actually got a real job.
Requiring only one or two of the easy things from that list is a perfectly reasonable entry requirement.
-dentin
Alter Aeon MUD
http://www.alteraeon.com
Alter Aeon Multiclass MUD - http://www.alteraeon.com
ADD is good, I like ADD. Everybody should be using it!
It works if you switch the ordering:
Good software development is to lego development as a chemist is to a cook.
temporal and spatial locality, and how your software maps onto hardware
Right - but if I catch a programmer ever actually implementing a quicksort by themselves though, they're fired. Because who knows - tomorrow they'll be thinking they can implement a database all on their own. That kind of thinking is the wrong kind of thinking. Unless you're looking at an academic career, where "error checking has been removed for clarity". No thanks, and good luck with that.
... it baffles me how many of them (university or otherwise "prepared") don't grasp basic concepts like common and basic data structures (e.g. hashmaps, linked lists) and the situations where particular structures are indicated (i.e. performance characteristics, etc.) and basic logic structures (case statements, try/catch/finally, ternary operators) and basic vocabulary (method, parameter, instantiate, etc.).
It's a monumental failure of the software engineering education system. How many carpenters get certified that don't know what a hammer and a chisel are? How many doctors graduate without a knowledge of a stethoscope and a reflex hammer?
Fuck everything else. Let's start with making sure no one graduates or gets certified without that basic knowledge. Then we can worry about the next step.
P.S.: The people I've been forced to mentor that don't know the above were not hired by me, and my recommendation was to terminate them immediately.
should be more widely understood than it is. Even English-only programmers need to know enough to avoid security holes. You can't normally be sure you're writing safe software unless you know a little about Unicode. In this sense, it's like structured programming, and unlike most other things on the original list.
perl -e 'fork||print for split//,"hahahaha"'
Your first bit is covered by structural programming (subroutines and functions).
So you are saying programmers should just be able to stick existing code blocks together with the appropriate software glue, which would be the closest analogy to assembling an engine like a piece of IKEA furniture.
These comments are my personal opinions and do not necessarily reflect the opinions of the other voices in my head.
You can get this on wikipedia. Try these pages:
https://en.wikipedia.org/wiki/List_of_algorithms
https://en.wikipedia.org/wiki/Category:Algorithms
The idea that code is nothing but a data structure
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.
Lexical scoping makes analysis easier for both the coder and the compiler.
Before lexical scoping languages like BASIC and FORTRAN were often nightmares of spaghetti code. If you've never experienced this you don't know how horrible it could be. Early C lacked it, but it didn't talk long to extend C to fix this mistake.
Since lexical scoping has become so common, there is no excuse for a language to omit it: I'm pointing at you, PHP and JavaScript. The fact that these two extremely common languages don't have lexical scope indicates a real failure in computing practice.
In some fundamental ways computing has made no progress. I think that this situation relates to the general unreliability of software and the problems that plague software development. When obvious best practice is not adopted, it should be no surprise that the same mistakes keep being made over and over again.
Why is Snark Required?
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.
'nuff said.
It's problem solving. It's breaking a problem down horizontally (layers) and vertically (features). It's reducing problems into the fundamentals and solving those first. It's prioritizing. It's learning what needs balancing, how to balance it, and why.
Programming is as much a work of art as it is an engineering exercise. Just like when creating a building, the architect and engineer have two diametrically opposing responsibilities, so does creating a program have the same challenge between design and engineering. Programming is figuring out how to walk that line between form and function.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Don't re-invent the wheel. But if you must, at least try to improve upon it.
I know this sounds strange at first, but before I learned assembler, I didn't really understand what was going on in the heart of the machine. If I were to introduce a programme starting from fundamentals, it would start with an easy assembler (eg Z80, 68000, PIC); this itself introduces the fundamental operations of programming, including assignment, de-referencing, LUTs, stacks, etc.
The next progression would be 'C'. This abstracts out the hardware dependency, but keeps the underlying structure.
This assists with more complex algorithm development, but also shows how the approach to programming developed from assembler.
Following that, I would move onto one of the modern 'C' successors. Personally I use C++, but maybe objective-C would be better.
It totally depends upon your purpose though.. If you want to cover UI/UX stuff, then you should think of a different approach. If you want to cover databases, that's something else again.
But in programming - IMO, the most genuinely 'useful' ideas are things like the registers and special registers that make up a CPU.
This comment was written with the intention to opt out of advertising.
If you got a hammer, everything looks like a nail.
If you got a stack.....
Ever heard of stack based databases? Yup they did (and probably still do) exist. But if you use them for the wrong purpose, you will get some performance problems. Throwing more iron(hardware) at it is not the right solution.....
and orthography in most cases.
Of the 8 virtues of the great programmer, humility is the most important. And I'm always right about that sort of thing.
Pretty much every efficient algorithm is in the O(n lg(n)) complexity class, and almost always this is due to a "divide and conquer" approach. The most important algorithm analysis tool is the Master Theorem, again because of its relation to divide-and-conquer algorithms.
Quicksort is divide-and-conquer with basically random quality of the divide, (base 2 non-natural) Mergesort is divide-and-conquer with perfect quality of the divide, Insertion sort is divide-and-conquer with worst quality of the divide.
Nowadays one can't overstress the impact of sequential memory access patterns over random access patterns, and the large impact of writes: even if it makes your algorithms longer, don't let them write back anything that is known to be already there.
Don't maintain what you can reconstitute: when sorting a doubly-linked list, just sort the forward links. You can reconstitute the backward links with a separate pass or in the last step. Of course, this conflicts with the "write only changed data" advice, but usually there is more movement than non-movement when going through all sorting stages.
The favorite data structure of the "MSc" "computer scientist" is the linear list. Now the linear list is a good starting point for perfect divide-and-conquer algorithms like mergesort. But for sloppy divide-and-conquer you are usually better off with trees or heaps. And the "computer scientists" have a fondness for using "worst-divide and conquer" algorithms with associated costs. And "buy bigger iron" does not help all that much against O(n^2) or worse.
They don't have to be able to write a compiler, but they should be able to write code.
the top-down approach results in code which is easily understood, elegant, efficient, robust, and maintainable
I often used (or resort to) down-top approach with good result and - maybe surprisingly - elegant and maintainable code.
My last code was a Python puzzle solving program.
I tried first the top-down analytical approach, and it seemed quite complicated and convoluted. I though of a complex data structure, to be refined.
Then I decided to code with down-top approach, build from small efficient task that I would need later for the job to be done, along with some test functions.
The data structure boiled down to a very simple one when I figured out that I could use recursion instead of managing a heap.
Finaly I had all the bricks I wanted, to finish the program. I just needed to figure out the main algorithm, I was worrying that it could be the tough part, but a miracle happened: the main function was a mere 4 lines, very clear and consise. They just popped out of my mind. What ? Is that all ? And guess what ? Yes, the puzzle solving was working right on the first time I ran it.
So I would rather say that when you have some good practices in programming, don't look upon Down-Top approach with contempt.
That's often a good way to go.
Divide and Conquer - not exclusive to programming but essential basic idea
A variant on the KISS theme:
If you deliver something that is better than "good enough" you're wasting your time and your clients' money.
You are not an artist. Every piece of code you write does not have to be a masterpiece.
Just because you think you can write a better version of someone else's code, don't bother if the code works.
i also want to know the best programming field in India.
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.
Here's a good practice: You should think through your logic, and have a clear idea of how the code should behave, before you start typing. Maybe write the comments before writing the code.
Once I inherited code from someone, whose author told me that he didn't know if a particular variable in the code was needed. (I ended up re-writing it.) If you think before you type, your code will be much easier to modify.
That's a good practice for a job interview, too. Once in an interview, I was told to write a C function on the whiteboard. I didn't want the interviewer to think I was a slow programmer. So I wrote code on the whiteboard without taking the time to think it through. He told me that was wrong. I then threw some other code on the whiteboard really fast. That was wrong also. Etc. If I had thought out the problem before writing code, I might have gotten the job.
"Complexity is easy. Simplicity is hard."
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.
Why doesn't Literate Programming ever make these lists?
http://www.literateprogramming.com/
Sad that fewer people own /read Literate Programming (Center for the Study of Language and Information - Lecture Notes) by Donald E. Knuth (Jun 1, 1992) than TAOCP.
Sphinx of black quartz, judge my vow.
At least she is capable of communicating without resorting to insults. Yeah, we get it, you were the smartest person at school but no one cared and you were bullied anyway, but with a 5-digit user ID you should really be over that by now. Get a gym pass if you want a punching bag. Intelligent people disagree sometimes, it doesn't mean one of them is an idiot, and insulting people doesn't make you look like the smartest guy in the room anyway.
It exists. It's called "The Art of Computer Programming" by Donald Knuth.
Listen, software development isn't the same as throwing some lines of code together. A lot of web developers seem to get away with it for a while, but it results in the kind of code that gets more and more expensive to maintain as time goes on. But it's great if the expected lifespan of the company is shorter than the time it takes for the code to become unmaintainable, which is true for most web companies.
It's also not the same as assembling some components into a program. In that case you're just configuring stuff, and yes, you don't need to know quicksort for that. You're also not a software developer.
A lot of people on this forum seem to have this weird concept of what software development is about, but that's why the salary range for a software developer is as big as it is.
There's not much point in copy-pasting an algorithm into your code - you need to apply it to the data structures and the logic in your application. In those cases where it is that simple, it's already in the standard library of your favorite programming language, you don't need to go looking on the web for it.
3 rules
- stay interested in anything and everything
- strive for simplicity, clarity, beauty, transparency (that also includes your progress when you develop stuff for someone)
- concepts, not implementation details (eg. understand OOP, not what the exact syntax for defining an object in language X is)
everything else is just details. Nobody should care about Language A vs. Language B or SQL vs. NoSQL as long as you pick what fits.
Lego development requires one HELL of a good knowledge of tooling design. I suppose somebody knows where the parting lines are on the Lego blocks, but they sure aren't noticeable. The interchangeable nature of all the blocks built in like forever shows that the Lego developer's skills in material science are also awesome.
The tooling design of most toy components is 'shrug,' make it all fit together. Particularly cheap toys. Lego was not developed like that.
Find me a mechanic that can build a V8. They don't have the metallurgy, the physics or the engineering to do it. That was a ridiculous example, and I wouldn't want to work for you.
That's an interesting way of looking at things, I suppose. By that definition of "build," a home builder would need a proper background in molecular biology (since they need to know the biological nuances of various flavors of wood), sufficient logging and milling technique (they don't grow in a 2x4" form factor, after all), architecture, geology and seismology (your home is only as good as the ground you build it on), glassworking (I'm assuming there will be windows), HVAC, interior decorating, metallurgy (nails, knobs, outlet box enclosures, etc.), culinary arts (for that fresh bread smell when you go to sell it), ...
This list is the best comment I've read here, but I think the point of using the best language / libraries for the problem domain you are working in is essential to include as a "useful idea" if not an essential starting point.
E.g. you should never write high level business logic in something like C or Python.
Now you just need to decide correctly which the best language / libraries are, so let the fun start on that debate.
As an aside, the real essentials in the list above are the even numbered ones (OK, let's include 5 as an honorary even number here to see where I stand)
I think databases, "The unix philosophy" etc. are more controversial and should not be on the essential shortlist.
I would say then do that list in Java, C and ASM.
I think this is a prime example of the vastness of the software development field. When I first started coding, the same argument was made about being able to write a compiler, and yet I'm expected to know this and a litany of emergent platforms, patterns, languages, and development environments. Lets face it, 95% of development is lego binding, and most of the time the pieces just have to fit together well enough. That modest performance gain you will get from your intimate knowledge of sorting algorithms will be much less important than whether your code is functional, concise and maintainable for the majority of programming jobs out there.
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
Maybe even get a gun license.
Because some people have no respect for what they create and who has to suffer what they created.
You can solve these issues by shooting them through the head twice. Second time just to make sure they dont get back up.
"All problems in computer science can be solved by another level of indirection"
(David Wheeler)
So true....
"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. ...
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'm sad to learn that, by your standards, I'm not currently a programmer, but merely a hack just out of high school, as I couldn't write a quicksort to save my life. Ironically, though, 20 years ago, when I WAS just out of high school (and WAY less experienced/skilled), I apparently was a programmer back then because I could and did write a quicksort at that time.
Or, maybe you're just really bad at expressing yourself.
Do not reach for your keyboard - especially if you are in a hurry
Step 1 Think about the problem
Step 2 Think some more about the problem
Step 3 Analyze the problem
Step 4 Review the specs one more time - if something is really hard - redefine the problem and go back to step 1.
Step 5 Design the solution
Step 6 Review steps 1-5 with someone else
Step 7 Revise Steps 1-5 if necessary
Step 8 Start coding.
Steps 1-7 are where great programmers are born.
That is absurd. There is absolutely no reason to have the various sorts memorized, no matter what you do for a living.
Library sorts are always faster than what you would implement on your own, which makes knowledge about sorts relevant to 90s era code, but completely obsolete now.
I've been writing code as a profession for the past decade from everything ranging from uControllers, cellphones, and SBCs to large (60+ server, each with unique functions, meshing multiple languages) ship control/interfacing systems.
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.
while(1) attack(People.Sandy);
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
...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.
Amm... you're saying fixing a custom engine is simpler than building an existing one? In most software projects, unless something you're fixing is tiny, it's almost always easier to just roll your own.
is well formatted code.
"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).
..that the only useful idea in programming it is to outsource somewhere they pay $1 a day!
To ask what the useful ideas are in 'programming' is like asking what the useful ideas are in 'writing'. There are a few very high level things like checking your work and think things through, but outside that the advice quickly becomes domain specific. Programming is explaining things to a machine, and thus what you are explaining and what kind of machine matter.
GOTO has a bad rap. The flexibility to jump to any location in code unconditionally with no requirement to return is a sadly lost benefit.
Code would be a lot cleaner if everything didn't have to be a freakin' function of something else.
Some (many?) of the greatest advancements in human knowledge were controversial at some point, and the people promoting them were often ridiculed. What makes you think that we are immune to that effect today in computing?
The single most useful idea in software development is the subroutine. It's what enables every thing else.
There are programming languages that get this wrong, although not recently.
I18N == Intergalacticization
1. 99.999% of end users/customers do not understand software design documents and never will understand software design documents. So we must prototype rapidly into existence so we can get useful feedback early and often directly from the people that will use the tools we build is important.
2. I rarely optimize for performance. But when I do, I always measure first, record the results, and after each change, measure again. Use a stop-watch, a routine you build yourself, or a fancy-pants Profiler that tells you how much time each line of code took, but never ever optimize without measuring.
3. Software Engineers/Programmers are usually religious fanatics when it comes to languages and tools. Almost any problem can be solved in almost any language. If you're on a project with someone who loves Java, they'll write better code in Java. This idea extends to OS choices. If someone loves the Mac OS, their programs written on the Mac OS will be much better than anything that programmer would ever write on Windows or Linux. 4.
IMHO BASIC was a great first language because of the goto statement. Let me explain why. Lots of people are familiar with or can easily understand a flowchart. By numbering the lines in a purely imperative language, people could easily get a machine to do something by laying the instructions out in order. Goto allows that linear list of instructions to be branched in exactly the same way a flowchart does (check condition, go here). Only after learning very simplistic imperative programming should one say "goto is evil, use structured programming". It's helpful - if unfortunate - to see the downside of goto in order to appreciate better code structure. But I remember there is more forethought required to use structured constructs to write some kinds of code. In the beginning I think it's important NOT to introduce abstract concepts (structured programming, OOP, complex data structures, etc) until the student has groked the fundamentals of getting the machine to do what you want. If all you've got is a hammer, everything looks like a nail, but then you will also have an appreciation and immediate understanding of the usefulness of power tools.
So I'm only slightly joking when I say "goto", but the point is that every abstraction looks like wierd arbitrary stuff you have to learn until you know enough to appreciate it's usefulness, at which point it's easy to learn because it does something you perceive as useful. Abstractions raise the height of the learning curve, but should not increase its slope or it shall look like a wall.
I'm still trying to understand why the latest craze is functional programming. From where I sit it's a bunch of intellectual self gratification. Programs manipulate data - why shun mutable state? Jumping through hoops (apparently something called monads) to have mutable data is absurd - that's what computers DO. Or as XKCD put it...
On the flip side of that is the hacks that sort by stuffing their data into a control, setting it's 'sorted' property to true, then reading it back out.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
If you want to inspire a young student with software development, tell them to find a way to fix software development.
The problem I am seeing today is that in spite of all the years we have been writing code, stuff is getting less reliable and stable and overall, I find the user experience of most technical things today appalling.
Obviously nothing that is being applied towards software development is working.
I find the Internet today to be worse then it ever has been. For instance I have a 50mbps connection and yet frequently I can't even load google.com because my browser tells me the connection is lost. How can today's broadband be even more unreliable then when I used to browse the internet using dialup?
I have a new Logitech remote that will freeze and not respond about 10 times an evening, in spite of about a dozen firmware updates applied already for it.
Most of the features of my "smart" TV are useless.
Games and Apps on my Android tablet or iPod Touch crash frequently and are updated regularly.
The most "advanced" OS on the planet, OS X, hangs on my every several days forcing a reboot.
There are rampant problems with a general lack of security of all digitally connected things. iOS 7 already has had 2 patches to fix security issues.
And I won't even touch all the issues that came out of Redmond over the years.
So there is a real big problem in software development, and it comes from people assuming they know how to write good software, but then, lets face it, good software is NOT being delivered today.
There needs to be a fundamental paradigm shift in how we develop software. The idea of releasing beta's, patching frequently, or Google's approach to update on a daily basis is no longer acceptable. There is no reason why "flawless" cannot be an objective to describe the user experience of using device or application. There is no reason why we cannot write flawless code. We have more processing power on our phones then we used to have on a supercomputer from 30 years ago, why can't we harness that power to develop a software process that produces zero bugs?
So, if you truly want to inspire a new generation of coders, forget about trying to entice then with current concepts in software development. Show them all the current problems with software development and then get them young minds thinking about solutions for a new era where software bugs and defects simply don't occur.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Breaking Bad reference?
You won't find any such list. I've made a career out of shunning all such "popular" attitudes. The more consistent the attitude, the more obvious the benefits to breaking away from it.
Way back in university, in CS, the prof spent a day teaching sorting algorithms, as all CS profs do. The conclusion was that you can't sort any faster than O(n,log n). Which made it all the more confusing when I asked him what I was doing wrong because my home-grown sorting algorithm runs in O(n).
Guess what. My puny zero-experience had written a sorting algorithm that really is O(n), and simply isn't taught in school. It's not taught as a standard sorting method purely because it depends high memory requirements and known a data range.
Put together your list. Get everyone to follow/teach/learn it. I'll make a living out of defying it when clients get frustrated that the industry seems to prioritize it's own principles over the actual business needs their clients.
I don't test. I don't allow database transactions. I refuse version control. I don't document. I don't write specs. I don't do garbage collection nor control. No complexity analysis, nor XML, nor functional programming nor object oriented programming. I type with a keyboard, but not with my variables. And, as we said before, my sorting algorithm is faster than quicksort.
Make your list. Then find out how many businesses consider such lists to be purely academic. Your "master programmer" teaches programming. He doesn't run a business.
Ah, I'm glad someone already hit this. I'd have gone with a more generic "readability" and "documentation", but yeah.
I'd also include a few more mathematically interesting algorithms that push graphics as well as algorithm and iterative design. Breshnam's circle algorithm comes to mind, as well as fractal programming. For very precocious kids, pushing a 3d object from scratch is a great way to learn (i.e. rotate a cube using nothing but the ability to turn on and off a pixel).
On the other hand, while I would definitely avoid complex libraries as the "genuinely useful" curriculum, most coding these days kind of eschews these concepts, for better or worse. Learning how to wrangle a .NET, Ruby, or Java library set is just as important these days. I'm not sure how to handle that in a core curriculum.
I was hoping to find someone that mentioned this already and mod them up, but no one has as yet.
Source Control
Ask any software developer worth his salt and he will tell you that they use source control.
When programming for fun or profit, this is how I start:
You may disagree about the rest (TDD), but step 1 stands. With all the great free source control tools available, there is no excuse for not using source control.
the growth in cynicism and rebellion has not been without cause
And I was stating the important parts of education here - anyone can hack up a sorting routine but in the real life business world the items I did list are what's causes the majority of the failures in projects. People not knowing their tools and inability to write code that can be maintained.
Don't waste time on writing your own sorting algorithm in a commercial application - it just wastes time and money for the project unless it's a very special kind of sorting that's unique to that project.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The power plug.
You should know that Real Professional Engineers won't like you calling yourself one. Anymore than Architects, Doctors or Lawyers would want you to call yourself a Doctor of Software or Database Plumber.
I think he meant build-by-plugging-together-like-lego-knockoffs-because-otherwise-this-analogy-doesn't-work software development for his comparison. Lego blocks are manufactured with 2-micron tolerances, so even if one were merely building something else with them the pieces would still all fit together perfectly.
. /* do what I'm thinking, dammit! */
.
.
include (DWIT);
.
.
.
if this is supposed to be a new economy, how come they still want my old fashioned money?
Just consider that in the majority of the business applications that floats around in the world right now that are built by programmers there's no real concern about how the sorting is done, the things that most people are concerned about is if it's correctly sorted according to their particular alphabet because if stuff comes out in the wrong order like "AÄÅBC....OÖ...Z" instead of "ABC...ZÅÄÖ" for Swedish people then that software is dead, no matter how smart the sorting algorithm is or what it's called.
This is the big deal - care about the whole system picture and leave the details to well-known well-documented standard routines. If my "ORDER BY" statement is done through Quick Sort or Bubble Sort or some other kind of sort is not of any concern as long as it does the right thing and is fast.
B.t.w. if you have that kind of employment criteria I suspect that you get more than the average share of esoteric people as employees.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
It might be interesting to know what sorts of problems you think fall into this category.
Not that I disagree with your general statement, but I find the "low skill" programming jobs tend to fall into some basic camps, like business tools, and e-commerce sites, and system administration. Almost all of these cases have much higher level tools available for solving the problems that simple programming. Much of the skill required is actually in configuration or manipulation of the tools components (which is not a insignificant skill set). For example web Content Management Systems (CMSs) replaced craploads of re-invent the wheel web programmers with people spending their time configuring drupal/whatever modules. And ERP software did the same for many business process programmers.
This doesn't mean that there aren't a bunch of programmers basically working on legacy systems that could be replaced by more modern packages, just that a lot of programming jobs seem to actually be SAP/Labview/whatever "administration" with some programming thrown in to fill in the gaps. The guys actually doing the heavy lifting for this stuff work at SAP/NI/Oracle/IBM/etc.
Find me a mechanic who's job description includes designing new engines, and I'll show you a mechanic that can build a V8 ;)
You Sir, are the idiot! As are the other moronic responses to Jane's post...
I haven't seen so many people missing the feckin' point.. What Jane Q.P. is saying is sooo true. Demonstrating you can implement an algorithm like QS (at the very least!) shows the right sort of mindset and aptitude you'd want in a DEV. She is not saying she expects every DEV to sit down and re-invent the wheel for every problem, but to apply that type of thinking to the greater problem.
I hate to think what sort of questions you would ask in an interview to find a decent DEV.
"Can you operate google?!" your HIRED!!!
Even I could cobble together stuff doing that... I agree... If you couldnt explain to me how to implement something LIKE QS in an interview, you buddy, are not hired!
Thanks,
James
Far worse than the programmer who doesn't know how to write a bubble sort is the programmer who insists on writing his own bubble sort, or memory management module, or any other piece of code that already exists in an adequate state. I have fired more than one for wasting my time and resources creating code that while well done required the other programmers to learn it, required maintenance, and delayed the project. If it already exists don't build it - unless it is the one thing on your critical path that is slowing your execution and you really, really, really critically need that time.
Useful skills related to programming, but not programming technology:
1) how to take a complex problem and break it down into simpler problems
2) how to reduce risk by slipstreaming accumulated small changes into a production changes (see 1, above)
3) build client trust by implementing the low-hanging fruit, first.
4) make yourself redundant through documentation and mentoring. It may not seem in your best interest, but it's the professional thing to do, and prods you to move on to other things.
5) Choose the right tools for the job
6) (Corollary to 5): If you're programming in XML, you're doing it wrong.
7) take time to think about a problem. If you think you have a solution, sit on your hands!: don't code until you've examined the drawbacks.
If you post it, they will read.
"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.
Yeah, agreed. This guy (gal?) is a twit, and I'd never work for him (her?).
As for the V8, I'd worry more about a chef that can't build a V8. I mean, it's just vegetable juice blend, right?
Personally, I'm a developer that doesn't know how to build a hashtable beyond just Hashtable blah = new Hashtable(); and I don't see a reason why I'd need to know how to do that from scratch, given the ease of just calling the constructor for a pre-built type.
Do I know what a hashtable is? Yes. Do I know its performance characteristics compared to, say, a raw array or a linked list? Yes. Do I know how to build one? No, and I don't need to. I stand on the shoulders of giants. I don't see a reason not to, since the giants aren't complaining about it. And if I ever did need to implement my own hashtable, I'm pretty sure I could figure it out.
The GP's attitude is not only elitist, it's also stupid, short-sighted, and inefficient. If the GP is a development manager somewhere, they should be fired if they ever let the attitude they posted here get a foothold in the workplace.
It underlies signal processing, video/audio compression, medical imaging, radio, and ton of other things too. A lot of technology we take for granted simply wouldn't be possible without it.
"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.
Related to your point. Know how to look things up in books or online and know how to ask the right questions.
I rarely know how to do something off the top of my head. The speed at which I can converge on a good example and/or tool kit and understand how to use it for my application is key.
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
your != you're. It never ceases to amaze me that people devoted to learning new languages on a six month cycle are unable to learn one...
"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.
Quicksort is already implemented a thousand times, so there's no need to implement it again, just find which library you need.
Quicksort is nice because it plays a little nicer with sequential data (improving cache hit rates and such), but unless you have a proper (and complicated) function for choosing the cut value, it ends up with an O(n^2) complexity in the worst case. HeapSort and MergeSort are guaranteed to run in O(nlogn) time, and while MergeSort requires O(nlogn) memory to operate in (while still playing nice with sequential reads), HeapSort does all of its sorting in place in the original array at the expense of trashing sequencing. All of the above need to be taught and understood by the student before being trusted with any serious algorithm work. The lessons you will learn from the tradeoffs and benefits of these three sorting algorithms translates well into absolutely everything else you may want to do in programming.
"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.
I can't really disagree with most of the stuff he mentions, but where's the mathematics? Statistics, graph theory, set theory, calculus, algebra and multidimensional algebra taken together provide the basis for the solution to a lot of hard problems. For one thing, how can you talk about optimisation if you don't know how about polynomials and exponentials.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Configuration Management. Simple, easy. Never had a formal class on in in HS or College, nor was it a section in a formal class.
I seem to remember a lot of language churn at both the university and industry in the 70s through 90s. Now I see some stability in languages and environments.- basically an OOP derivative of C like Java/Scala or C#. And an OS derived from UNIX/Linux which inlcude iOS and Android. The most churn I see now are cloud OSes or web-services.
We've been a Java shop for almost 20 years now.
The sooner you start to code the longer the project is going to take.
I mean we`re all using it... right?
... are too specific. The concept of an Atomic Operation is important; database transactions are just a domain-specific example.
Is that really a problem? It's a pretty good way to introduce the concept, because the whole idea of data consistency is easy to get you head round with a bunch of tables.
Besides, what other computer paradigm comes with the tools to implement atomicity as standard? Under most OO systems you have to unwind the changes in exception handlers... and that's before you get to something as basic as C.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Not to mention the tolerances! Most people have no idea just how precise they have to be in order to hold together yet easily pull apart like that.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
How is that programmer going to have any idea what existing parts are suitable or not if he has no idea how to write even the fundamentals from scratch if necessary?
Naturally, you don't want the guy who will ignore the fine QS already in the system library and write his own (unless there is a very good justification based on a particular problem). You also don't want the guy who never had a single clue why QS is better than Bubble.
So you hire the guy who can and has written a QS once but has the sense to use the one that comes for free in the library.
Your response has nothing to do with the post you replied to.
By that standard, Jeremy Clarkson is an expert programmer. Therefore, that is a terrible analogy!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
There is definitely some truth to what you say. I started out as a programmer in 2007 but quit programming and went into infrastructure/systems engineering after my first programming job precisely because of what you just described. I got into computers and programming initially because I had a desire to cultivate a deep understanding of the computer and how it worked, and I discovered very quickly that modern programming is all about the latest "shiny new framework" and slapping something together as quickly as you can (the politically correct term for this is, of course, agile). That's all well and good, and there is a definite place for that because speed to market is very important in a competitive environment. And a lot of people really seem to enjoy that style of rapid development at the expense of truly understanding what is going on. But it wasn't for me.
That said, there is also truth to what the grandparent said when he posted this:
Those people with the "fragile sort of knowledge" are at everyone's mercy when things go wrong. They literally have no clue where to go next or how to troubleshoot if things don't work exactly right. And in my company, it's me and others at the heart of the infrastructure devops teams who they come to when things go down, because we are the ones who actually understand how it all really works underneath the high level frameworks and scaffolding. We understand the networking, the HTTP, the authentication protocols, languages and everything else at the bottom. The best programmers, at least at this company, are the ones who did those rapid development jobs for just a few years and moved as quickly as they could into backend "Developer Center of Excellence" type teams, where their job is to support other developers, create standards, write programs designed for the infrastructure as a whole and therefore learn the deeper points of the technologies.
Conclusion: The grandparent is right when he says that the best programmers understand how things work under the hood and could write these objects from scratch if they had to. But you are right when you say that not all programmers have to be at that level in order to do something effective. Both types are essential to organization, because you have to have people fast enough to outmaneuver the competition, but also really solid people in reserve to back up the quick and dirty developers when things go wrong.
Beware of bugs in the above code; I have only proved it correct, not tried it.
rebuilding is not building. that's why they don't call it building...
This. I think there is a corollary here. The algorithms you use to solve problems are also useful for doing anything, like reading or writing code, or thinking.
Divide and conquer is not just to solve the problems, but it is also a way to *think* about problems.
Like wise with binary search and sorting
Well, I don't know where did you take a chemistry example from... But keep in mind that this phrase only got said because chemists are required to know software development nowadays.
Rethinking email
Code that's successful tends to last a lot longer than its creators anticipated, so lay that foundation carefully. It's usually worth investing effort to do it as right as possible the first time. Doing it "quick and dirty" is the equivalent of mailing somebody a bomb, and often the recipient of that bomb will be you.
That said, there are some fantastic programmers in the quick-n-dirty catagory. Use them effectively--to throw together proofs of concept and demos, to explore alternate implementations, etc. Just don't let them manage the whole damn project.
As the codebase gets larger and older, collecting dependencies along the way, it gets exponentially more expensive to redesign/rework components. Sometimes those are the only good ways to fix bugs, so you'll end up with not-so-good band-aid fixes instead. Then, your technical debt is growing exponentially along with your codebase.
A master of software programming, I seriously doubt he would recommend I learn Javascript.
I am Bennett Haselton! I am Bennett Haselton!
...programmers go "what could possibly go wrong."
That's their DNA.
The best skill, I think, is being able to quickly diagnose problems with code.
Being employed as a general help desk person at a University computing lab back in the '80s taught me how to read code quickly, how to identify why it failed quickly, and to explain to the befuddled student why it failed. (We weren't supposed to do that - course teaching assistants were expected to do that - but in the flood of incoming people, we had to do that.) The last part - explaining to someone why it failed is (I think) the most important part. You didn't want these people coming back, so you had to learn how to tailor your explanation to different people very quickly.
Once you've done it for one language or API, you can do it again and again for other languages and APIs.
Guess who gets the call if what I want is a tasty meal?
Haven't seen it mentioned yet, but state machines are incredibly useful.
Well, I don't disagree with you either, necessarily. But regarding terminology, I would call your "backend" people "programmers", and the other guys "hacks".
Just as a rivet-pounder building a bridge is not an engineer.
We don't always agree, but well put, sir. (This and your original post.)
The thing non-experts always neglect when thinking about high performance is the importance of cache locality and memory locality... and the fact that these can often dominate even algorithmic improvements (for realistic N).
HAND.
This simple idea is used in all branches of engineering. It's basically prototyping. You never build the full-blown complex system from scratch. You start with a simple prototype. If that works, you increase complexity and add features. Adding features increases cost, but if you have demonstrated feasibility, it's much easier to get the customer to pay.
Yes, in the event that we are stranded on a desert island with no internet access, but somehow have a working computer with a compiler but no standard libraries and we need to write a sorting algorithm, but the computational efficiency of the sort is incredibly important. In that case, you should be able to write a quicksort from memory. Let's all invest some more effort into staving off this scenario. Because we should not be able to prioritize according to likely need.
A lot of the best tips out there revolve around making your code maintainable. Some of the best ways to do this looking into test-driven development, refactoring, keeping your code modular and strongly cohesive, learning to identify smells, learn dependency breaking techniques, write quality documentation (UML, comments), learn design patterns, study algorithms, etc. There are various books out there covering these topics and all of them are pretty language neutral.
First, read this:
Knuth: The Art of Computer Programming, Volumes 1-4A Boxed Set
http://www.amazon.com/Computer-Programming-Volumes-1-4A-Boxed/dp/0321751043
Then read this:
https://www.sans.org/top25-software-errors/
Everything else is a niche.
Not to mention the tolerances! Most people have no idea just how precise they have to be in order to hold together yet easily pull apart like that.
The first time they pick up some megablocks or other imitations, they get a pretty good idea.
I'm sad to learn that, by your standards, I'm not currently a programmer, but merely a hack just out of high school, as I couldn't write a quicksort to save my life. Ironically, though, 20 years ago, when I WAS just out of high school (and WAY less experienced/skilled), I apparently was a programmer back then because I could and did write a quicksort at that time.
That is kind of sad. Could you describe how quicksort works, at least? Does divide and conquer ring a bell? How about a pivot element? I'm not going to require you to do it in-place or anything. If you've forgotten how to program I'm not sure what to say, except that you have my condolences.
You mean like Heapsort? One of those algos that most computer science programs still require you to write, just to prove you understand how to implement a heap?
A good compiler, as pointed out elsewhere in this discussion (look for lisp and closures) can be implemented in very few steps for the right language, and still be complete and usable.
Hugh Pickens DOT com is the new Mrbabyman
Andrew Hunt and David Thomas have done this already. This book contains the universal truths of programming, from a high-level perspective. It addresses analysis, coding, dealing with management, planning for the inevitable shitstorm, and even keeping yourself sharp as a programmer. Their book is the one book I would recommend to any programmer, from novice to expert. Further, I would recommend that you buy it, keep it, and reread it every couple of years. The concepts therein will be applicable to any programming you will do in any language and in any environment.
How about being curious and enjoying solving math story problems?
"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 read what you posted very carefully and what I posted still stands. Although I could do this there is no reason to so why SHOULD I bother when Googling for an optimized free solution is quicker. Providing I understand everything that the code I find does and it is unencumbered by licence restrictions then that is fine, that does not mean I would make knowing how to rewrite a 30 year old, hardly used (in code we actually write anyway) algorithm part of a recruitment process for new developers.
I dont read
Concept programming is the simple idea that the concept is not the code, and that being aware of the differences matters.
See http://xlr.sourceforge.net/Concept%20Programming%20Presentation.pdf for more details.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Write an assembler. Write a compiler. Write an operating system.
+1 good sir.
It is incredible how many people think they can be useful programmers just by being API monkeys.
Which is why hash tables are overused.
If you aren't capable of building those libraries if you had to, you shouldn't be using them. You shouldn't be programming at all.
Use more GOTO statements.
You aren't describing programmers, you are talking about assembly line workers.
He was talking about professional programmers.
You are talking about people who get paid at $12-$15 an hour as compared to $100,000+ software professionals.
Code: The Hidden Language of Computer Hardware and Software
The Annotated Turing: A Guided Tour Through Alan Turing's Historic Paper on Computability and the Turing Machine
Both by Charles Petzold
Easy to read and once you understand both books, you will be much further in understanding computers and computation than 95% of programmers. Sad, but true.
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 is actually quite interesting. I suspect that the requirement to build code that is maintainable is currently less important than being able to get something out there quickly. In my experience, that leads to programmers who copy code around the source base; who do 'micro fixes' rather than larger fixes that might lower overall costs; that write giant routines that work well but don't factor well; things like that. I'm no longer a programmer, but I remember when that sort of code was frowned upon. No longer; the important thing is to do it quickly, get it running, because the technology is changing such that you'll probably throw the whole thing out in a year or two. Why waste time on elegance when it is throw away? Everything is a demo these days.
Go to Heaven for the climate, Hell for the company -- Mark Twain
Short story. I used to work with a woman who was a fairly high paid programmer. She had a masters degree in CS from some university in Belgium. Unfortunately, she did not understand hash tables, their use, or the benefits. She did every programming job we gave her using linked lists. These lists were often thousands of elements long, and had short, unique text labels. There was a hash table facility built into the system library. We patiently helped her move her linked lists into using the hash table facility, but she persisted in using those damned linked lists on everything new. When you have a hammer, everything looks like a nail. Everybody who gets out of school in CS should understand the basics.
Go to Heaven for the climate, Hell for the company -- Mark Twain
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.
However, you know the difference between a bubble sort and a quick sort, right? You don't need to be able to code them to understand when they might be useful, and when to apply them. That is the sort of knowledge that is important to have.
Being able to reproduce a qsort in C during an interview isn't required, I think. Knowing where to use it, how to set up the data structures: that is the skill I want people to have for a C programming job.
Go to Heaven for the climate, Hell for the company -- Mark Twain
Relational databases are firmly defined by set theory and what is easier to understand really than Venn diagrams?
All processes are functions and XML docs are really just S-expessions so what could be easier and simpler than using LISP (and in particular the interpreted LISP 1.x-like newLISP which can double for any scripting duties and has the ability to interface both with RDBMS's and C/C++ runtime libraries, among others?)
C when you absolutely, positively have to and only on sections of code that need it for performance tuning ~5%.
What are you going to do when your hashtable doesn't perform as it should? Would you even know?
Real world example: early versions of Java only used the first 10 characters of a String in the hashcode. This is fine for some uses, but horrific for others. It's a shortcut you can only safely perform if you know your domain - it's certainly not safe in the general case.
What's the big-O of insert in a hashtable? O(1)? Nope: O(n) worst case.
It's only O(1) amortized - if you're choosing a hashtable you are choosing a hash function and a growth and a collision policy. How will you do that if you don't know how hashtables work?
Actually, I was not talking about expert programmers (which you can still find at a handful of companies like Apple and Google), but about "programmers" who just throw a bunch of libraries together. A lot of software and hardware companies would indeed hire Jeremy Clarkson to design a kitchen blender. Unfortunately.
I'm sad to learn that, by your standards, I'm not currently a programmer, but merely a hack just out of high school, as I couldn't write a quicksort to save my life. Ironically, though, 20 years ago, when I WAS just out of high school (and WAY less experienced/skilled), I apparently was a programmer back then because I could and did write a quicksort at that time.
That is kind of sad. Could you describe how quicksort works, at least? Does divide and conquer ring a bell? How about a pivot element? I'm not going to require you to do it in-place or anything. If you've forgotten how to program I'm not sure what to say, except that you have my condolences.
Why is it at all sad that, after 20 years, I've forgotten the implementation details of a specific algorithm that I've NEVER had to implement (other than as part of the learning process back then) since it's already been implemented in the standard library of just about every language or API that I've ever worked with (and that implementation has probably been done better than I could do it, because it has likely been done by someone who has studied sorting algorithms in much more detail than I ever did)? What does that have to do with forgetting how to program? I rebuilt an engine in high school, but I don't remember how to do it now. Does that mean I've forgotten how to repair my car, too?
And how does it work? Well, I could tell you now, since the curious part of me went and looked it up on wikipedia to refresh my memory the second I finished making that post. And you might think that's fine, since that proves I can actually do it, except for the fact that, had I first ran into Jane Q. Public in an interview rather than on slashdot, I would have failed that requirement at the time.
But to answer your question with the knowledge I had at that time, the only part of it I could remember is that divide and conquer is part of it. But I couldn't remember how it dealt with getting values sorted between the left and right halves (doing a rough sort before dividing), nor anything about the pivot point or how to select it.
Points taken; I spend a lot of time in the man pages and other references. I think the part I misinterpreted was the "I couldn't write a quicksort to save my life", which if taken literally means an inability to write simple programs. What I think you meant was "I couldn't write a quicksort in a few minutes without spending some time looking up reference material." I think anyone who has studied computer science should be able to come up with quicksort given enough time and motivation (and pencil and paper, at least). The concepts of divide and conquer and in-place array operations are just too basic to programming for something like quicksort to not eventually be developed by a competent programmer.
One of the things that should be on the list is proficiency in at least one language. For example, if one learns C#, Java, C++ ... then one has learned the basic syntax of a whole list of languages, or BASIC etc. And, learn how to use btrees, linked list and all that other stuff ...
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.
... except for everything that is a potential security risk, which is everything that potentially faces the Internet, which in 2013 is everything.
Congratulations. You've just demonstrated in two sentences why the entire Internet ecosystem today is a huge gaping security disaster.
("But my script will never see the Internet! All our workstations are behind a firewall!" Let me introduce you to my little friend called "Bring Your Own Device". Did I say friend? I meant the kind of friend who likes hurting people. Good luck!)
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
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.
... given constantly changing and contradictory specifications, hardware, operating systems, programming platforms and data storage and transmission standards, on unmanaged, obsolete and malfunctioning endpoints, while preserving full round-trip data and binary code compatibility with legacy systems dating back thirty to fifty years, in an international multilingual ennvironment with competing national legal frameworks and data stewardship requirements, over an inherently hostile network, managed by uneducated users, while leaking no data or access rights in the face of organised crime and state-level espionage agencies.
And that's just to begin to meet basic functional square-one user requirements on today's Internet.
No pressure.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Load Accumulator (lda)
Add an integer (add)
Store Accumulator (sta)
Most CS graduates have no idea what this is, and that's the problem with CS.
cursethedarkness
As somebody who used to be known as an "anti-OOP troll" (even had slashdot stories around my writings), I've generally come to conclude that OOP has its place, but that place is not everywhere. Some projects or some parts of some projects benefit from it, others become more tangled because if it.
It's another tool in the development tool-box; just don't use one tool for everything. The hard part is knowing when to use what tool, and that has yet to be scientifically investigated; and so is still a gray art.
I find OO is sometimes useful for name-space management, but if you try to use it like the original OO books suggested you use it -- to build models of domains (such as employees, customers, store products, etc.), then you make a mess and compete with database modeling, duplicating concepts.
Lately I see some Functional Programming (FP) proponents making similar hyped claims to what OOP proponents did in OOP's heyday. FP is the new OOP. FP has a place, but that place is not everywhere.
There is a hype cycle in this business. New ideas are good to cultivate and explore, but early proponents often get carried away.
Table-ized A.I.
Relational databases are stupid, we should use graph databases.