Lately I've been getting professional work, hanging out with other programmers, and making friends in the industry. The only thing is I'm 100% self-taught. It's caused my style to extremely deviate from the style of those that are properly trained. The techniques and organization of my code are different.

It's a mixture of several things I do. I tend to blend several programming paradigms together like Functional and OO. I lean to the Functional side more than OO, but I see the use of OO when something would make more sense as an abstract entity—like a game object. Next I also go the simple route when doing something. When in contrast, it seems like sometimes the code I see from professional programmers is complicated for the sake of it! I use lots of closures. And lastly, I'm not the best commenter. I find it easier just to read through my code than reading the comment. And most cases I just end up reading the code even if there are comments. Plus I've been told that, because of how simply I write my code, it's very easy to read it.

I hear professionally trained programmers go on and on about things like unit tests, something I've never used before so I haven't even the faintest idea of what they are or how they work. Lots and lots of underscores "_", which aren't really my taste. Most of the techniques I use are straight from me, or a few books I've read. Don't know anything about MVC, I've heard a lot about it though with things like backbone.js. I think it's a way to organize an application. It just confuses me though because by now I've made my own organizational structures.

It's a bit of a pain. I can't use template applications at all when learning something new like with Ubuntu's Quickly. I have trouble understanding code that I can tell is from someone trained. Complete OO programming really leaves a bad taste in my mouth, yet that seems to be what EVERYONE else is strictly using.

It's left me not that confident in the look of my code, or wondering whether I'll cause sparks when joining a company or maybe contributing to open source projects. In fact I'm rather scared of the fact that people will eventually be checking out my code.

Is this just something normal any programmer goes through or should I really look to change up my techniques?

Answer: Challenge Yourself (41 Votes)

"In fact I'm rather scared of the fact that people will eventually be checking out my code."

Good. Being conscious that people are going to look at your code will make you try harder.

Programming has become an incredibly large field. There are dozens of topics, tools, niches, and specializations, some of which are whole careers unto themselves. There is a vast amount to learn and know, and when you work with other programmers, there will always be stuff you know that they don't and stuff they know that you don't. This is a good thing.

If you are worried that your experience is incomplete, there are plenty of steps you can take to amend that through formal education and collaboration with trained experts. But it sounds like you're afraid there's some quantifiable milestone after which people say "Okay, now that I've mastered that, I'm officially a programmer." There is no such milestone. I've definitely had moments where I thought "yeah, now I'm getting somewhere" after I learned something new, but there's no magic list of things you must know and do to call yourself a programmer.

I know a lot of things about programming, I've used a dozen languages in lots of projects, and yet the subset of programming knowledge I can call my own is tiny. And I like that. Frankly, a programmer isn't something you are. A programmer is something you are constantly learning to be.

Take honest inventory of your skills, your strengths and weaknesses. Get feedback from people with more experience than you. Look for positions that line up pretty well with where you think you are—but don't be afraid to go for jobs that are a little outside your current mastery. If you only take jobs you already know everything about, you'll never learn at work.

Answer: Don't Just Type There, Do Something (2 Votes)

As many people have pointed out, you can never become a master programmer. You can never really master any language. I laid out my entire programming foundation on HTML 4.01, and lo and behold, HTML5 threw itself in my face like an apple pie. The same happened with CSS3. Everything is just constantly evolving, improving—and I don't think there is such thing as a programmer who is not self-taught.

To some extent, we all learn things on our own—they don't teach you everything when you go to college for computer science or software engineering. A lot is left in your hands. And even then, every programmer acquires their own unique style over time. Sure, there are methods and standards when it comes to "good code," but there is still variation from person to person, and another program shouldn't tell you that your way is wrong.

I think there is a certain camaraderie to be upheld among programmers, and that is one of tolerance and respect, as cheesy as it may sound, towards each other and our methods.

"I have trouble understanding code that I can tell is from someone trained," you say.

Any decent programmer, though, would add comments in their code—it is the slightest of courtesies, and not every programmer may know it, but the collective work of us as colleagues is based on what we all do and how we contribute to the cloud that is programming.

You also write, "it's left me not that confident in the look of my code, or wondering whether I'll cause sparks when joining a company or maybe contributing to open source projects."

It's important to know that on an individual basis, it is also an endlessly growing/improvement process. You will probably never again code the way you do right now. I know that in the past six years that I've dipped into programming, my techniques (and even indentation and visual layout habits) have changed drastically, and they constantly are.

Another important thing is to always be confident in your code. If there is something wrong, another programmer will no doubt have constructive revisions to make. Sure, there will be a few who won't, and there will be a few who will toss away code they don't like, but it's all part of a truly remarkable learning process.

That's also what Stack Overflow and this site are for—so we can learn from each other, ask each other about ways to do specific things, and just be helpful to each other in this growing internet culture, community, and climate. So, it is in all of our best interest to continue on our neverending journey down self-taught lane, and to make the best of this great community we've all chosen to take part in.

62 Reader Comments

Well, that's how I started out, and after 30 years in the industry I am currently a senior systems and performance engineer for a tier-one mobile phone manufacturer. As for my coding style differing from others - over time I have, though self-study, adopted many of the "best practices" promoted by leaders in the field - though many of those I had self-discovered before I encountered them (Booch, et al). I have been published (both in tech magazines and in academic books), been an invited presenter at major tech conferences and workshops (IEEE, ACM, etc), and have US patents for adaptive systems to my credit. So, formal training is not required, although it may well be advisable - breaking into the field as a self-taught engineer is a LOT harder now than in the past.

Maybe the world has changed in the last decade since I retired. But, in the world I woked in, coding skill did not have much value. Most of the value was in knowledge of the domain that was being modeled in the professional software. Back in the 1980's, a large bureaucratic company like IBM could afford to make an effot to impose coding standards on its developers. But, the reality of the small Silicon Valley startup where I worked for a couple of years after retirements was run and gun. People are pressed to take indivicual responsibility to get a job done and it is largely left up to them what their code looks like. The emergence of a tenth rate language like Javascript should be enough to demonstrate the kind of standards that dominate the real world.

Maybe slightly off-topic, but it might be relevent. If you are self-taught, do you specialize?

As he said, programming is a very large field. Here's a different perspective. With the explosion in th e number programming languages and paradigms (procedure, OO, etc) the majority of programmers have become capable in multiple languages. I call these folks "generalists". They are invaluable on teams for coding and as a great resource for other programmers who might not be skilled in a particular area.

The less common role is that of a "specialist" like myself. I have been a database programmer for about 25 years. I started in VAX Fortran in the 80's (yes we had a database written in that!), then Oracle for 20 years and currently Teradata. The common language through them all is SQL. I know very little about OO, Java, or web programming. However, my knowledge of databases and SQL is very deep. What specialists bring to a team is the deeper experience that generalists don't always have. Just like generalists are a resource for others, so is a specialist. We crack the difficult problems the generalists sometimes can't. We also tend to be able to produce solid, well documented code much faster since we know the language so well. (again, this is true only within our narrow range of expertise).

I read articles about how specialists are dinosaurs and will soon be extinct. If you specialize in a language that is sunsetting, then yes. If you specialize in something that has a much longer lifespan like SQL or databases, you will be needed for a long time.

In a nutshell, great teams are made of of both types. They complement each other and can learn from each other. Both however, abide by the shop's standards. This includes code standards, documentation, testing, the whole lifecycle. Be prepared to adapt to the shop environment, but also realize you bring knowledge and techniques that the shop might find very valuable.

As the old saying goes, "Well written code is it's own heaven; poorly written code is its own hell".

A lot of older developers are self-taught from day one since the current emphasis on a CS degree wasn't there when they started working. And eventually, any developer becomes mostly self-taught as the job is one of constantly learning. Besides, you don't really learn languages and techniques in college, you learn fundamentals and concepts.

If you know what the various paradigms really are and are *choosing* to blend them together for functional or performance reasons, you are doing very, very well. If you are blending them together because you don't really understand them, doing some remedial training -- on your own or otherwise -- may be called for.

And yes, you really, really need to start writing concise, clear comments in your code. If you end up returning to a project after a couple of years, trust me, your coding style will have changed enough that you will be a little lost in your own code. (And you will probably say "what was I thinking?!" We all do.)

Jump in. No matter, you are going to have to adjust to what a particular shop or team does or their style -- over and over every time you change jobs. Any job you get, I can guarantee you that as a junior programmer you will still know something the most senior programmer doesn't. Programming teams teach each other; it's not a one way flow of information.

Sounds to me like the person is doing alright... and paradigms (functional/oop example) are actually mixed more often than you would expect. In truth, I did not attend a school that was exceptionally well known for its computer science program, and I felt I learned a LOT more working with more experienced developers. I eventually developed my own style which involves commenting and coding clarity over performance where I can get away with it. I don't want people wondering why I did what I did.

I've been programming professionally since 1999, and I still don't like people checking out my code, in case they find a really ridiculous bug or they complain about the style, naming conventions, the fact that I use "Option Strict On" (VB.NET) and so on.

I always add comments to my code. They're as much for my use (when I revisit the code later) as for the use of others. I add doc comments to the code to provide Intellisense in VS.NET. I use lots of white space and name my variables sensibly.

I would have thought that those habits might be fairly common, but with my current employer, they are not. No-one writes comments. No-one follows proper naming conventions (Pascal/Camel/etc). White space is used sparingly, and one ex-colleague of mine didn't use *any* at all (or comments, so reading his code was like reading "Ulysses"). People use key words and .NET class names as variable names and column names in SQL ("External", "Type", "Object").

I hate underscores too. The only time I use them is as a prefix for class-level variables.

The greatest programmers have two huge important differentiators, IMO: (1) they comment everything without being asked to do so and will press others to do the same (read: they want you to know how their code works, what it does, and be able to carry on in the event they get hit by a bus) and (2) they know that there is no "best language" but, rather, there are loads of different languages used for different reasons and the more important part is applying logic to solve problems.

Author, in a very wordy fashion you tell us you are self-taught and try to convince us that is okay...even better than pros. Why? I don't understand the purpose of your article. Self aggrandizing at best.

To me, writing professional and good code is about writing easy-to-understand code, because reading and debugging code is a lot harder than writing it so if a "pro" writes at his/her highest level, complex and elegant, the code is both hard or impossible for others especially "juniors" to read, and likely very, very annoying to debug.

So if your code is easy to read, without comments (or a few here and there declaring intent, like if you need a weird construct for performance reasons), then you're writing professional code imo. To be a bit personal and rash, I'd say OOP and DDD nerds in particular tend to architect unreadable messes with 9+ levels of abstraction and multiple inheritance everywhere. Don't do that, unless it's a very, very special occasion ^^

And of course, you should follow the code standard of the project you do maintenance work on, regardless of how much it sucks or goes against your personal beliefs. Mixing styles and standards makes it even worse, use your preferred or industry best practice standards when new projects are made instead.

If you don't have a code standard at the workplace and it's "all around a mess" then you need to introduce one, and work hard to make your coworkers accept and adopt it. That's also part of being a "pro" imo - you need to fix both people, businesses and software.

tl;dr: if you find it hard to read a senior's code, I'd say that code needs to be simplified to be maintainable in the future. Even using complex paradigms should at least make sense when read by someone with basic knowledge of the language and domain in question.

A professional knows what needs to be done and does it. The corollary is that a professional knows what doesn't need to be done, and doesn't waste time.

Pay attention to your colleagues, figure out what needs to be done, and do it. That may mean writing unit tests. Or checking in with a project manager. Or simply committing a config file into version control.

Thank you for this informative article and to all who commented. As a self-tought hobbyist programmer, I have received a lot of advice and encouragement from professional friends -- both on how to improve my programming style, and on how little CS education actually gives towards making anyone a programmer. Anything beyond core principles is learned through doing it, and I have heard numerous stories about fresh graduates incapable of coding a FizzBuzz algorithm: http://www.codinghorror.com/blog/2007/0 ... ogram.html

Leather Rope wrote:

Author, in a very wordy fashion you tell us you are self-taught and try to convince us that is okay...even better than pros. Why? I don't understand the purpose of your article. Self aggrandizing at best.

I come from the embedded systems world, so a lot of what we do is slightly different from the commercial applications world. But from that perspective:

1. Money is everything. Fast and functional beats perfect every time. In any field of engineering, there's the 'right' way and the way it's done in the real world. When you're learning (either in school or from a book) about how to design a system they tend not to mention the critical money plays. But money is the single most important consideration in any system design. Before you ever write a single line of code you need to ask "how much will this cost".

2. Shallow is better than deep. Object Oriented and Functional programming are great 'on paper' theories about coding. But they have a tendency to encourage programming styles that are horrible in the real world because they create 'deep' code (code that needs to pass through all sorts of different functions before it passes control back to your O/S). Unfortunately, that sort of code is a nightmare to test and debug. One tiny quirk in an object 27 calls deep can waste weeks of your time. If your code is too deep, your unit testers might just fail your code on the basis of it taking too much time to test.

4. Don't over-comment and keep your code short. The ideal function is one where the reader can pull up the entire function on a single screen and know what it does. You don't need to comment every line - indeed, if you're finding yourself putting a ton of comments alongside the body of the code, your function is probably too complex and should be broken up.

5. Don't wait around for inputs. Whether you're dealing with databases or digital signals, you don't want your function to sit around idling for inputs that may never come. If you don't have the data necessary to resolve the function, you need to exit the function and return control to the O/S. If you can't do that, you need to restructure your code so that you can.

I think of coding as a craft - something like carpentry or metalworking. The code that I write is my product, just as much as the compiled binary is, because the compiled binary will be around for a month or two - perhaps longer, if you're on a long release cycle - but the code will probably live on for years.

I'd get very nervous if the electrician wiring my house didn't want any other electricians to look at his work.

If you're not proud of what you've written, be honest about it - acknowledge the shortcuts, compromises and shortcomings of your approach, in comments where appropriate, and in the release documentation. Somewhere, at some point, someone is going to have to read the code you wrote and make changes to it. You want that poor soul to be happy he's reading *your* code.

@jollyllama2: I couldn't agree more. Always take pride in your work. We have team code reviews here where we walk through code line by line on a jumbo screen. Everybody sees every line of code, every comment. When you put your code up on the screen, you should be proud of your work, but also humble enough to accept informed suggestions/criticisms from your peers. That's once of the differences between an amateur and a professional: a pro learned to leave their ego at the door during a code review.

Take pride in your work, and always ask yourself "could I be doing this any better"?

" I find it easier just to read through my code than reading the comment. And most cases I just end up reading the code even if there are comments. Plus I've been told that, because of how simply I write my code, it's very easy to read it."That's like telling someone 'well i can read my own handwriting' Commenting is a courtesy and in some situations a job/contractual requirement. It's 10% for you 90% for the next person."I have trouble understanding code that I can tell is from someone trained. Complete OO programming really leaves a bad taste in my mouth, yet that seems to be what EVERYONE else is strictly using."I bet they had comments in their code? Or did you not look or think what does // mean or <!-- for etcThe point is they do it for a living and you don't so there is at least one thing they are doing right that you can learn.

"joining a company or maybe contributing to open source projects. In fact I'm rather scared of the fact that people will eventually be checking out my code.""**SPOILER** I hate to be the one who ruins this for you but if you contribute on an open source project.....SOMEONE IS GOING TO LOOK AT YOUR CODE!!! How are you supposed to get any better if you aren't willing to take feedback on your work? Or at least say can you look at this to a more experienced person. Every company where coding pas the bills there is someone who is going to review. Even John Carmack has said in interviews he tries to review his programmers code as much as possible so he can not only catch things, but also see what they are doing and use it as an opportunity to teach them something and on top of that he wishes he had more time to do that.

I got a master in CS and electrical engineering but I only had a few intro courses in programming. For sure I programmed in quite a lot of courses, but they where not about programming.

School can teach you lots of things, but programming mainly comes from practice and programming with others. Add caring about it and time and you will get better at it. Before you work with large code bases that's been around a while it's hard to understand what is a reasonable practice.

Something that feel amateurish to me is not adjusting to the style of the code base you work in. When there is a million lines of code there already, your code should probably look the same, both "code standard"-wise and in style. When it comes to style it often more important that everybody does is similarly rather than in the best way possible.

I'm from a game-programming background, and since you've mentioned "game objects", i'm assuming you've dabbled in it too so I'll speak in that context.

The reason why code sometimes looks complicated for the sake of it, is because whover did it was coding with versatility/robustness in mind. Particularly so with games, because game design tends to change a lot during a long production cycle, I try to anticipate potential changes or features that could be added, so when a designer surprises us with his new 'awesome' ideas, I wouldn't have to rewrite that much code.

This isn't nearly as complicated as it sounds - after working on a few projects you'll sort of understand why things were done in a certain way. I believe my greatest skill is in figuring out how other people's code works, and this has helped catapult me into a lead-programmer position after just a year of industry experience (this, and the fact that I was keen to learn as much as possible and kept volunteering to code things I've never done before).

The most important lesson I've learned from my ex boss was to focus on the architecture of your game (at the game level, not engine level). In particular, everything to do with game object life cycles (i.e. how your game objects are created, managed, accessed and destroyed). In some cases, it may be a pre-defined pool of objects, or a factory that creates them on the fly, or some sort of object-manager that only allows you to access objects via message passing instead of exposing pointers, etc. This may sound trivial, but is a great place to start.

I find that OO helps when dealing with larger-scale games, but ONLY IF USED PROPERLY. By following textbook OO examples I've seen, I've ended up painting myself into a corner. Likewise, I've also written monolithic blocks of code (functions that span hundreds of lines of code) that were nearly impossible to debug. The good thing about making such mistakes, is that it helps me appreciate the decisions that the more experienced guys have made.

Last but not least, I believe the best way to improve is to join a company and volunteer to do things you've never done before (in baby steps, of course). This may result in a lot of self-learning, but at least you'll be paid to do it, and you're likely to have good reference material in the form of existing code and more experienced people to answer your questions. I'm a Computer Science grad and had been trying to teach myself game programming for years (after work, in an unrelated field) and got nowhere. In contrast, I had learned so much more within a month of joining a games studio.

You need to take you ego out of the equation. It blinds you to a lot of stuff including how much your code sucks.

Your mind sees this construct of beauty you want it to see and ignores all the crud. Have someone else look at your code and take the ego blinders off.

The psychology of computer programming was a great book back in the day, and still a good book but very punch-cards-versus-terminals dated.

Can anyone vouch for "Code Complete". It seems to be in the same colaborative vein but a little more modern.

Great comment. Lose the ego, and become someone people want to work with.

Steve McConnell's Code Complete is brilliant. Every programmer should read it. It teaches great techniques that save time and money in the long term. Realise why *every* if statement should have curly brackets!

My very first programming job out of uni, my boss printed out my code, and marked it up with a red pen. There were something like 348 "defects". Once my bottom lip stopped quivering, I fixed them up, realised my "I'm a great programmer" University-instilled belief had been destroyed, understood the value of code reviews, and I got on with learning how to be a better programmer. Still learning after 20 years.

Anyone that talks about "strict OO" means you're either talking c++, java or php. It's just a given anywhere else. If I were starting over new today in the coding world I would stay as far as possible away from java. "Strict OO" is yet another design pattern for the sake of design patterns that fill the java (and c#) world -- since you already know and use functional programming you've already detected that there is a faster, leaner, better way to write these same "design patterns." OO is certainly very useful for some things, as is a functional style in other places. Neither are the solution to every problem (I'm sure lispers would disagree

I'd say: do as you please, but at least make sure you understand why pros do things the way they do. If you don't, you don't have the whole story, you're in the dark. If you do, you can agree or disagree, it's an informed opinion already.

For example: not understanding why comments are useful. You write your own code, it's so good you can still read it after a year. That's good. But in the case of a large company, a year after, it's not you that reads the code, it's the new guy that just joined the team. And he reads:

int f(x) { return x+7; }

Clear as daylight. But can he tell that the function was originally supposed to add 5? Not without a comment!

Pro coding is not so much about individual skills as it is about adhering to a set of rules that will let people hop on and off the team - because that's life. It's also often about cutting every corner that can be cut in order to meet arbitrary deadlines, but that's another story.

I would say go for it. I spent many years studying for a CS degree and a PhD and my software engineering skills only really improved when I had to work on real world projects and work with other developers. The fact you are asking this question means you should go for it as you have shown the one thing that many University educated developers lack, self awareness and critic. As along as you always remember that there is no such thing as a software development pro, there are always improvements that can be made. Always look at your code critically, never do something without justifying why you are doing it and you will improve rapidly.

Doing is learning so the more you do the more you will learn. Good Luck, Scott

So, this is coming from the perspective of a computer engineer with a background in scientific programming and large system design (in aerospace).

I think there is a large conflation in the programming world of coding skill and knowledge of languages with design skill. A lot of the programmers I know tend to design as they code, and equate the generation of code with the maturity of their design. To the contrary, coding should be the last thing you do ... it's the instantiation of the design ... and the major skill of programmers (distinct from software/product designers for the purposes of this discussion) should be knowing how to take a design, identify the languages and tools that best suit the design, and instantiate the design effectively using those tools. To that end, what makes a great programmer is knowledge of a suite of tools (mostly languages) and the ability to translate requirements (or other design descriptions) into functioning code effectively. When I read the original question, I see a person who has knowledge of the tools, but doesn't understand the engineering/design process enough to know where he sits in the overall product engineering flow (not knowing about unit testing is a big flag for me). I would suggest getting more experience coding, absolutely, but it would also help immensely learning how design and product teams work, and that may also help you understand the tool choices and patterns you see when you look at various products (when to use OOO, why a program is organized a certain way, why one language is better for a given application, etc).

(That point could also serve as a great starting point for a discussion about what CS education is/should be, and what skills a software company should be looking for.)

I think there is a large conflation in the programming world of coding skill and knowledge of languages with design skill. A lot of the programmers I know tend to design as they code, and equate the generation of code with the maturity of their design. To the contrary, coding should be the last thing you do ... it's the instantiation of the design ... and the major skill of programmers (distinct from software/product designers for the purposes of this discussion) should be knowing how to take a design, identify the languages and tools that best suit the design, and instantiate the design effectively using those tools.

I would be careful here. Design skill greatly matters, most programmers are weak around design.

But the idea that coding is the last thing you do I emphatically disagree with. That reminds me of the days of the "waterfall" process: let's get the design all figured out and perfect and only then we can code it up.

That doesn't work, pretty much because one can never get things right in advance. Even if you theoretically could, by the time you finally get around to coding things have changed enough to upset everything. The last serious project I participated in that worked this way was a large air traffic control system, and that was millions of dollars wasted, ultimately.

The development process works best in the "iterative" approach, doing it all at once: design, implement, test, again and again, feeling one's way around, making mistakes, adapting to changes and new ideas.

Also, just what do you write this wonderful design in? Some other language? UML? In my not so humble opinion, it's code that works the best for expressing it. Sure a few diagrams can serve as a roadmap to communicate the essence when needed, but the details are best described in the very code that will serve to implement it, not some other formalism.

I will also snipe at "software" engineers who don't or can't code: they usually don't know what they are talking about, being so long disconnected from the practical consequences of often overly grand mechanisms and frameworks.

I've been programming since I was 8 years old and my family got a Commodore Vic-20.I wouldn't say I am self taught.I was taught by some of the best programmers of my time.They showed me their code in Magazines and Books and I happily read them, copied them, adapted them and learnt from them.I would say I'm self learned though.

30 years later, I can quite easily write in many different languages.VB, C++, C#, PHP, Javascript, Perl, Ruby and many others.

These days having a degree in IT/CS will give you an advantage when it comes to a job interview over a self learnt person but in this game experience also counts.So if you're just starting out I would highly recommend getting some form of qualification even if you never use it.

"Going Pro" really is more up to you than your schooling though.I've seen graduates that write horrible code and I've also seen people who have never done a degree write simply beautiful code.

All said how "professional" you are is up to you, not your training.

Even though I have no formal training in IT/CS I AM still a professional. (And still learning!)

Well, that isn't correct for sure... the code should be perfectly readable without comments. Sure if you're forced to write something knotty a comment or two might help but code that is littered with comments is an absolute nightmare.

If I read that I'd think some cowboy hacker had written in. First off its using a magic number, second it has a single letter variableName, and 3d it has a non-descriptive function name. Major fail on every point.

I've been coding for 35 years and still feel the same way you do. I just haven't let this stop me from having a successful career in programming. I adjust and adapt my style to fit the shop I work in, and never hesitate to ask questions and seek new techniques from my peers. Like you, though, there are aspects of modern coding that I do not prefer to use. I call some of the techniques I see the 'running around the block three times before going in a straight line' style and prefer a more simple and direct approach. This doesn't mean that I don't learn the technique, but unless the requirement calls for something that abstracted, I usually prefer not to use it.

I think there is a large conflation in the programming world of coding skill and knowledge of languages with design skill. A lot of the programmers I know tend to design as they code, and equate the generation of code with the maturity of their design. To the contrary, coding should be the last thing you do ... it's the instantiation of the design ... and the major skill of programmers (distinct from software/product designers for the purposes of this discussion) should be knowing how to take a design, identify the languages and tools that best suit the design, and instantiate the design effectively using those tools.

The "design-as-you-code" approach is 'philosophically' not how its supposed to be done, but it's actually a far better solution for most projects.

With mature products you're iterating with an established group of coders, you design first because you can. You understand the system well enough that you're not going to get blindsided by unexpected oddities.

But most products don't work like that. They're "R&D"-style projects where you're working on a platform (whether software, hardware or both) that is relatively unfamiliar to your team. The white papers give you a general sense of how to use various elements, but they don't include all the little glitchy features you really need to know for effective system design. In the commercial applications world, you have to deal with everything from development environments to O/S's to libraries being updated on a regular basis.

In such projects what ends up happening with the design-first-code-second approach is that you have a tendency to get stuck in a 'design loop' where you discover that your design simply doesn't work once you get to the coding step.

So what you do instead is you code while you design. You have an overall architecture in mind and then you start coding critical sub-functions to learn all of the potential pitfalls - and then you base your design on those coding exercises.

However, once you've gotten enough knowledge about the potential pitfalls to actually do a good design you've probably got 95% of the code down already. At which point you simply treat it like a mature product, finish up your design, fill in that 5% with perfunctory coding and go into testing.

This is not an 'inferior' method but simply a matter of expediency. No one masters a platform without coding in it, so either you can send your entire team off for 6 months to learn how to code in it on meaningless problems or you can simply have them learn on the project you actually want completed.

Well, that isn't correct for sure... the code should be perfectly readable without comments. Sure if you're forced to write something knotty a comment or two might help but code that is littered with comments is an absolute nightmare.

I think the idea—perhaps just phrased incorrectly—is actually "any decent programmer would document their code", and that you can do both by commenting logic aspects that might not be easily understandable and by writing readable code. So via function and variable naming along you can guess at what the code does, but you also have comments on algorithm parts that might not be completely obvious from the get go (especially to a non-specialist).