Ask Slashdot: How Do You Make Novice Programmers More Professional?

Slashdot reader peetm describes himself as a software engineer, programmer, lecturer, and old man. But how can he teach the next generation how to code more professionally? I have to put together a three-hour (maximum) workshop for novice programmers -- people with mostly no formal training and who are probably flying by the seat of their pants (and quite possibly dangerous in doing so). I want to encourage them to think more as a professional developer would. Ideally, I want to give them some sort of practicals to do to articulate and demonstrate this, rather than just "present" stuff on best practices... If you were putting this together, what would you say and include?
This raises the question of not only what you'd teach -- whether it's variable naming, modular programming, test-driven development, or the importance of commenting -- but also how you'd teach it. So leave your best answers in the comments. How do you make novice programmers more professional?

Comments

Very simple

[Anonymous Coward]

Let them accumulate experience and wisdom, and when they achieve it then tell them they're too old to work in this field.

Re:Very simple

[Narcocide]

+1 insightful

Re: Very simple

[Anonymous Coward]

Make them. code object oriented... Every little thing is its own few lines of code, so everybody is equally confused.
Remind them the old days are gone 'programmers' can't talk to senior executives to find out essential business rules. They have to....
Go to endless Scrum meetings, submit requests, and wait for days while said executives prevaricate.
Meetings are run by arrogant Scrum experts, who ghave never coded, yet will not have made redundant when you are.
You are demanded to give a schedule, and you move infantile sticky note characters from TV cartoons, which are your avatars ikyn... On. Some white board. You invent a schedule, it's a fantasy, due to the prevarication of above mentioned executives.
Then they put you on testing... When you suggest the printed tests have gaps, you are told not to worry .... Best get this in writing, they will try to vblame you when things go wrong later.
When it all works, after many unpaid evenings, you get rewarded with a pizza.

Re:Very simple

[ATMAvatar]

Time for carousel. Renew! Renew! Renew!

Re:Very simple

[No Longer an AC]

They only have three hours in which to do this.

Personally, I'd suggest beating them over the heads with printed copies of man pages whilst trying to emphasize the importance of commenting their goddammed code.

But that's just me.

Re: Very simple

[LesFerg]

I... I could laugh... or cry... been there done that... did you stay in development or start selling shoes?

Re: Very simple

[Rei]

Object oriented is a good idea, so long as they have experience doing so (at least in school or at home). If not, just tell them to try to keep all of their functions down to less than X lines. Each with a very explicit name, to the point that the function name itself is practically a comment.

I'd also print out the following and have it near their desk:

----------
RULES FOR OPTIMIZATION:

1) Don't.
2) (Experts Only) Don't yet.
----------

I remember when I was starting out, being able to right "fast" code felt like the mark of a good programmer, and often rendered code unreadable and bug-prone by optimizing sections that had no business being optimized in the first place. It took time to learn that good programming is clear, easy to understand programming, with optimization done by first identifying a problem, profiling the code to see what's actually consuming cycles, and focusing on the low-hanging fruit therein.

Part of it also was that a lot of the "optimizations" aren't actually optimizations. For example, loop unrolling, and very often loop checks, the compiler does that for you, so I was just uglifying my code for no good reason and getting full of myself for "optimizing" when I was doing no such thing. My interest in people writing "fast" code however led to me reading Carmack and Abrash, which led to getting a better understanding of what actually helps vs. what's a waste of time, and where to focus your efforts.

Re:Very simple

[Rei]

I'd rather teach them to keep their functions short and their function titles descriptive, so that the code comments itself. Nothing annoys me more than comments like:

for (i = 0; i < 3; i++) // Loop three times
{
      some_fn();
}

Comments should be about why, not what. What should be easily visible in your code on its own.

Re: Very simple

[Anonymous Coward]

Why 3 times?
Why some_fn() when we could also use some_other_fn()?

Code can be self descriptive in what it does. Comments provide WHY.

Re: Very simple

[Anonymous Coward]

stupid mobile site. cut off your mention of why in the original comment. sorry for repeating what you already said.

Re: Very simple

[Applehu Akbar]

+1 Painfully True.

Re:Very simple

[Applehu Akbar]

"Comments should be about why, not what. What should be easily visible in your code on its own."

Think of it as comments needing to be one level above the code. Function and section header descriptions should be two levels above.

Re: Very simple

[Anonymous Coward]

Dont forget they have to train their foreign replacement

Re:Very simple

[Ash Vince]

They only have three hours in which to do this.

Personally, I'd suggest beating them over the heads with printed copies of man pages whilst trying to emphasize the importance of commenting their goddammed code.

But that's just me.

If code needs comments your probably doing it wrong. Code should instead be broken down into small units with meaningful method names and tests.

There are certain edge cases where you need to include a comment because you might be doing something strange then the comment can explain why you doing, for the most part though the code should be easy to follow just by reading through the method names.

Oh, and while we are on the subject, as soon as you use And in a method name really try and split it into two seperate functions.

  Change:

function doThisAndThat(...)

Into
function doThis(...)

function doThat(...)

Even if both of those methods will always be called together one after the other for the rest of eternity that it still far than the alternative which is that some fool after wards comes along and changes it into: doThisAndThatAndTheOtherThing(...)

Re:Very simple

[dougdonovan]

How Do You Make Novice Programmers More Professional?...you don't, they do it on their own, if programming is in the blood, they'll make it happen on their own.

Re:Very simple

[CanadianMacFan]

You forgot the part that they have to train their H1-B replacement if they want their severance pay.

Re: Very simple

[Pig Hogger]

rendered code unreadable and bug-prone by optimizing sections that had no business being optimized in the first place. It took time to learn that good programming is clear, easy to understand programming, with optimization done by first identifying a problem, profiling the code to see what's actually consuming cycles, and focusing on the low-hanging fruit therein.

— sigh —

35 years ago, when I started programming, my pro programming mentor told me exactly that.

Re:Very simple

[ChrisMaple]

Breaking code into small units results in excessive call / return pairs and consequent poor performance.

Replacing comments with descriptive method names causes hard-to-read long lines.
Comments have several audiences, including the original programmer, people familiar with the project who have to support or modify the code, and complete strangers who have to figure out what everything does. Descriptive names alone don't do the job, and having to read tests to understand the code means having to double the number of windows open at once to understand the code.

Re:Very simple

[shmlco]

"Breaking code into small units results in excessive call / return pairs and consequent poor performance..."

Or not, depending on your environment. Breaking OOP code into small parts, for example, can make an object easier to subclass. And in some modern languages, like Swift, smaller functions may in fact be inlined into other functions and loops by the compiler/optimizer.

Creating massive functions simply because you assume that such code is more performant is a classic case of pre-optimization and, 99 times out of 100, doesn't matter anyway. Whereas code readability and maintainability matters a great deal.

Re: Very simple

[shmlco]

If you're looking at someone else's code (or even your own, a year later), would you rather see...

for (i = 0; i 3; i++) // Loop three times
{
            some_fn(i);
}

Or...

for t in 0.. MAX_TASKS {
            scheduler.grantTimesliceToTask(t);
}

Not only was the first comment worthless, the second version is entirely readable and understandable without it. Refactored and with a good comment, the code might be... // BUG-484 Background tasks stalled while waiting for network requests, so...
scheduler.serviceBackgroundTasks()

Again, and as mentioned, the what is now obvious, but the comment explains WHY you're doing this rather odd thing at this point in time.

Re:Very simple

[dlingman]

Oh, and while we are on the subject, as soon as you use And in a method name really try and split it into two seperate functions.

  Change:

function doThisAndThat(...)

Into
function doThis(...)

function doThat(...)

Even if both of those methods will always be called together one after the other for the rest of eternity that it still far than the alternative which is that some fool after wards comes along and changes it into: doThisAndThatAndTheOtherThing(...)

But I thought HaltAndCatchFire was supposed to be an atomic action. Now I need to code it as two separate functions?

Re:Very simple

[No Longer an AC]

That's a fair point. I have seen comments just for the sake of saying the code is commented. /* MAIN */
int main(.....

etcetera

Re: Very simple

[helixcode123]

If you're looking at someone else's code (or even your own, a year later), would you rather see...

for (i = 0; i 3; i++) // Loop three times { some_fn(i); }

Or...

for t in 0.. MAX_TASKS { scheduler.grantTimesliceToTask(t); }

Hmm.. Looks like an off-by-one bug. Should probably be
for t in 0.. (MAX_TASKS -1)

Re: Very simple

[Anonymous Coward]

led to me reading Carmack and Abrash

I assume by Abrash you're talking about the black book, but what Carmack were you reading? I'd love to read some tips from him.

Re:Very simple

[No Longer an AC]

I don't entirely disagree with you, but I'm reminded of code I've written that I revisited months later and asked myself what I was doing.

It was probably bad code, but when I wrote it I obviously thought it was the best solution at the time. And no clear comment as to why I did that.

The function may have a comment at the top of it, but the details are messy and convoluted.

Also, I'm reminded of something I read once that claimed COBOL was self-documenting. I thought that was funny.

There's also an old quote (maybe I saw it here on /.) that goes something like this:

I don't need comments. If it was hard to program it should be hard to understand.

I would also enforce error checking.

Re:Very simple

[Anonymous Coward]

Because that won't compile due to comment placed between ) and { I suppose?

(Seriously though I mostly agree, but would re-phrase as "break code into sensible sized, logically delineated blocks" as there are many cases where the quest for really short functions split over many files just leads to fragmentation and confusion.

Re:Very simple

[Anonymous Coward]

I never quite got why C programmers are so obsessive about using i, j, k etc. for loop variables. It makes for much more understandable code if you use sensible variable names even as loop counters.

for (task_num = 0; task_num < TOTAL_TASKS; task_num++)

> "Comments should be about why, not what."

So true. I had a C instructor who told us he wanted us to comment our programs, but don't just repeat what the code is doing as a comment. He gave an example:

a = 3; /* set value of a to 3 */

"Anyone who does this will be SHOT!"

Re: Very simple

[Anonymous Coward]

If those two functions will be called together "forever and in all eternity", as you say, then there's probably a better, single name that captures the semantics of the conjunction:

getCatsAndGetDogs -> getAnimals

Re: Very simple

[losfromla]

No, magazine subscriptions, of course.

Re: Very simple

[david_thornley]

I once got a major speedup in a program by rolling up the main loops as tight as they would go. I'm not exactly sure why this helped, but I suspect it had something to do with locality.

Re: Very simple

[cthulhu11]

You forgot not obsessing over a new language every three years just for the sake of trendiness.

Re: Very simple

[Anonymous Coward]

'Carmack and Abrash' can you suggest specific papers at all?

Re:Very simple

[No Longer an AC]

How is task_num any more descriptive that i, j or k?

I've got to iterate a number of times. If I use i for a variable I know it's something I will throw away after use (usually after a loop).

Calling it task_num implies it may be more important and someone might be tempted to use it later when it was nothing but a throwaway variable.

i was just an index into an array ('i' for index maybe? 'j' and 'k' being the next letters in the alphabet if more are needed?)

I've also been known to use 'x', 'y' and 'z'. I never liked 'a', 'b' and 'c' for some reason though.

I'm all in favor of using descriptive variable names, but sometimes a simple 'i' will do and like another poster said it's more important to say why you're iterating than that you are iterating.

Re:Very simple

[Anonymous Coward]

> How is task_num any more descriptive that i, j or k?

Are you kidding?

If you use I, j, k and you have to put in a comment explaining what they stand for, you're doing it wrong.

Parent gave an example of "looping 3 times." What are you looping? Why 3 times? 3 is just a magic number in that case. What does it stand for?

Granted, i,j,k are fine for trivial loops where context is not important. What I'm talking about is when programmers use them only because they hate typing long identifiers. That kind of laziness costs maintainers time.

Focus on a few key things

[Registered Coward v2]

In 3 hours you will be able to cover 5 or 6 things in enough detail to really explain them so you need to focus on what you think it i critical for a novice to know. I would start with identifying hat would you have liked to have known when you started out, then list the critical error you see novices make consistently, and then identify any critical skills a novice needs to have. Once you have that list, pick the 5 or 6 you think are the most valuable and over them.

Re:Focus on a few key things

[ShanghaiBill]

My company hires many young non-degreed self-taught programmers (because that is all we can find). We give them a reading list, and require them to spend about four hours per week doing professional reading and studying on their own time. The books include "Clean Code", "Programming Pearls", "The Pragmatic Programmer", several books on algorithms, code complexity, and books on software engineering such as "The Mythical Man-Month" and "Joel on Software". A lot of it is stuff that they would have learned if they had a CS degree. They can substitute books of their own choosing with pre-approval.

Many of these younglings have matured into great programmers. I hired one guy while he was a junior in high school. He worked for several years, and then decided to go to college, and ended up getting a PhD from Stanford.

Re:Focus on a few key things

[phantomfive]

. We give them a reading list, and require them to spend about four hours per week doing professional reading and studying on their own time. The books include "Clean Code", "Programming Pearls", "The Pragmatic Programmer", several books on algorithms, code complexity, and books on software engineering such as "The Mythical Man-Month" and "Joel on Software".

So, question........how do you ensure that they actually read them?

Re: Focus on a few key things

[Anonymous Coward]

This is actually a pretty great way to get to the goal. Any programmer-to-be that's willing to do the time and read these tomes is willing to learn the art of programming. These are hires even if they don't know the ropes.

Re:Focus on a few key things

[bill_mcgonigle]

because that is all we can find

Is there an implicit "for cheap" at the end there? Because lots of old guys are frequently bellyaching here about how after age 40/50 they can't get any work (and one presumes they know the ropes by then).

Re:Focus on a few key things

[Ichijo]

My company hires many young non-degreed self-taught programmers (because that is all we can find).

Let me guess. You only try to hire people who are looking for a job. Am I right?

Re:Focus on a few key things

[Narcocide]

The reading list is obviously chosen from a select set of things that outline skills they're expected to know to do their jobs. If you're someone who has already read these books and understood them then it's pretty easy to see who finished and understood the reading assignments just by reviewing their code.

Re:Focus on a few key things

[Narcocide]

Cheap and pretty is always implied.

Re:Focus on a few key things

[RevDisk]

Could we get a full list of those books?

Re:Focus on a few key things

[Anonymous Coward]

on their own time.

It's good that early on, you're weening them away from the fiction that their time doesn't belong to the company.

Re:Focus on a few key things

[Anonymous Coward]

That's a tight reading list!

Re:Focus on a few key things

[ShanghaiBill]

Is there an implicit "for cheap" at the end there?

No. When we make an offer, it is almost never rejected as being "too low". In fact, it is seldom rejected at all. We just don't get enough qualified applicants (CS degrees AND actually able to write code (the first does not imply the second)). This is in San Jose, California.

Because lots of old guys are frequently bellyaching here about how after age 40/50 they can't get any work

By the time someone is 40-50, they should have a broad skillset, and a deep network of former colleagues. The old guys whining about being unable to find a job are mostly turds that have serially rejected and their former co-workers are glad to be rid of them. There are a LOT of people like that out there. These are the guys you remember from college who wanted to copy your assignment an hour before it was due, because they had no idea how to do it themselves, the dead weight on your programming team, and now they are old.

(and one presumes they know the ropes by then).

That is a really bad presumption. I give every interviewee a random problem from ProjectEuler. I am amazed at 40-50 year old "professional programmers" that can't come up with a solution. My 14 year old daughter has done over 100 of them, typically in about 20 minutes each.

Re:Focus on a few key things

[Anonymous Coward]

In my experience, the 40/50 year old guys with experience and a willingness to keep their skills up to date don't have to look for employment - it finds them, especially if they've got good recommendations and/or are willing to have some mobility. They're still quite capable of pulling down $300K as a consultant or being a respected team lead.

Its the ones who think that their experience writing a 100K line Perl script in 2006 qualifies them to be a Software Architect for a multi-million dollar eCommerce company using Rails or AngularJS without the need to have learnt anything about the developments in the industry since then that have the problem.

On the other end of the age spectrum, we also get the guy who designed a Tinder clone as their sole project thinking they're suddenly the next Kernighan and Ritchie (sadly, they know not who these two are).

It's the entitlement that kills them (although, sadly, age discrimination is all to real as well but not as much as you';d think IMO).

We need a lot more coders - fewer software engineers and even fewer software architects (I'm talking about the sheer number of positions in an organization). When I go looking for software developers, I also look at folks like these referenced as well - ones who enjoy the coding aspect, are willing to learn and be taught good coding practices. In my experience, the ones who come out of college want to do Software Engineering or Architecture and would often look down on developer positions as a step back.

But please do snark away. Its quite entertaining.

Re:Focus on a few key things

[Anonymous Coward]

By the time someone is 40-50, they should have a broad skillset, and a deep network of former colleagues. The old guys whining about being unable to find a job are mostly turds that have serially rejected and their former co-workers are glad to be rid of them. There are a LOT of people like that out there. These are the guys you remember from college who wanted to copy your assignment an hour before it was due, because they had no idea how to do it themselves, the dead weight on your programming team, and now they are old.

Condescending asshole, you're forgetting about the entire generation of socially awkward nerds whose childhood coincided with the personal computer revolution, who grew up interacting with machines instead of people, who never learned social skills, and who never accumulated a professional network because they'd rather not interact with people like you. Those were the technically inclined kids who were doing all your programming assignments while you dead weight bastard cheated your way through college. Those nerd kids grew up, and they're literally 40-year-old virgins now. Until recently they were able to make a decent living using only their technical skills, until social scum like you forced the socially awkward out of the industry which they built for you.

Re:Focus on a few key things

[ShanghaiBill]

So, question........how do you ensure that they actually read them?

I ask them what they thought of the book, what they learned from it, and what questions they have that the book didn't answer.

These are self-taught people that passed a rigorous interview process consisting mostly of coding. They want to learn. I have never caught any of them faking their professional development.

Re:Focus on a few key things

[ShanghaiBill]

It's good that early on, you're weening them away from the fiction that their time doesn't belong to the company.

You don't do professional development for "the company". You do it for yourself.

Re:Focus on a few key things

[phantomfive]

These are self-taught people that passed a rigorous interview process consisting mostly of coding. They want to learn.

Good point.

Re:Focus on a few key things

[ShanghaiBill]

Could we get a full list of those books?

This is the list I currently use. I welcome additional recommendations. What CS books have you read recently that you really wished you had read 10 years ago?

Programming:
Clean Code
Code Complete
Programming Pearls
The Pragmatic Programmer
Regular Expressions
Algorithms by Robert Sedgewick
Introduction to Algorithms by Tom Cormen
Hacker's Delight by Henry Warren

Interface design:
Don't Make Me Think
The Design of Everyday Things
Microinteractions

Software Engineering:
The Mythical Man-Month
Joel on Software
Test Driven Development

Theory:
The Turing Omnibus
Deep Learning, by Goodfellow, Bengio, Courville
Concrete Mathematics by Donald Knuth
Physics for Game Developers
Computability, Complexity, and Languages

Re:Focus on a few key things

[Anonymous Coward]

managers and executives who hold them accountable, in big loud angry silverback gorilla words, when their shit gets into production still broken.

But that's hard to pull off anymore. Too many of them/us are special snotflakes [sic], with fragile egos, and we were hard to find in the first place, and instead of making it right, will simper and run off to HR at the first chance.

I know I really hate it when the stuff I push to production does not work right.

In many ways, resultant code output quality comes down to the developer or team. If they don't care... But if management no longer cares, or today's management buzzword bingo has landed on "shit early, shit often", well...

Especially if management believes they can bypass their "high priced talent" for an outsourcing company at some perceived cost benefit, well...

Pride in workmanship, whether its digital or physical, does not seem to be valued or held much in high esteem anymore.

(Workmanship "design", "architecture" purity, etc.)

Re: Focus on a few key things

[Anonymous Coward]

Nice list.
Design Patterns
Metrics and Models in Software Quality Engineering
Site Reliability Engineering

Re:Focus on a few key things

[johannesg]

Project Euler is a test of math skills, not programming skills. The two are often conflated, but in reality overlap only rarely. In many branches of programming you can function very well while knowing nothing more than what +, -, *, and / do.

Moreover, the problems are arranged in chains that lead up from basic understanding to advanced understanding. Simply dumping one at random into the lap of an unprepared person is very likely to weed out all the excellent programmers, leaving only math students - who I'm guessing aren't responding to your ads to begin with. So that's your problem right there: you ask for one skillset, and then you are surprised that your test for another skillset isn't working out. It isn't the quality of your candidates. It's you.

If this wasn't clear enough: I've been programming since the eighties, I have my masters degree, and somehow they trust the software I write controlling (which literally means "deciding life and death of") spacecraft costing 300 million euro and up. If I ever fuck up I guarantee you _will_ read about it here on slashdot. Yet somehow I have _never_ needed to determine if a number is prime, or indeed any of the other circus tricks at Project Euler.

Re:Focus on a few key things

[Anonymous Coward]

Hats off to you for giving people a chance who haven't had to self teach themselves a bunch of graph and tree algorithms first to pass an interview test. I wish more employers had that attitude rather than expecting entry level self taught developers to have mid level skills + CS major knowledge already. I think the higher expectations placed on self taught programmers and their own concerns about being viewed as lower than developers with CS majors is why many actually end up putting a lot more effort into learning. Whereas the CS major, especially one from a top university, may think they're already set and have less to prove.

Re:Focus on a few key things

[UnknownSoldier]

Great list! However you missed the one quintessential CS book.

Godel, Escher, Bach: An Eternal Golden Braid

--
It's 2017, and /. STILL can't properly display Unicode?! GÃdel *sigh*

Re:Focus on a few key things

[ShanghaiBill]

Project Euler is a test of math skills, not programming skills.

Junior high school math. I haven't seen any that require any trig or calculus. My daughter is in 9th grade, and has taken algebra and geometry, and learned Python last year. She hasn't had any trouble with the first 100 problems.

I agree that they require little programming skill. That is why they are a good test of minimal ability.

Here is a sample problem:

A palindromic number reads the same both ways. The largest palindrome made from the product of two 2-digit numbers is 9009 = 91 × 99.
Find the largest palindrome made from the product of two 3-digit numbers.

Would you hire someone that cannot solve that in 20 minutes?

Here is my daughter's solution:

#!/usr/bin/env python

def main():
    max = 0
    list=[]
    for a in range(100, 1000):
        b0 = max // a
        for b in range(b0, 1000):
            n = a*b
            if ((n // 100000) == (n % 10)): ## This is to speed it up
                    if(str(n) == str(n)[::-1]):
                            max = n
    print("Max: %d" % max)
main()

Re:Focus on a few key things

[Anonymous Coward]

That's easy, if they can actually write code, they must not have read any of that bilge.

Re:Focus on a few key things

[dougg76]

Questions not relevant to the actual job done are not a good indicator of future success. These types of questions are great for recent students or people who enjoy riddles problems though. There is a whole field of study about learning and testing. There has been numerous studies done showing that these types of things don't correlate. Interviewers use them because they are a cheap and fast way to weed people out.

Colleges should add a pedagogy classes to help interviewers understand how to test people more effectively, and to understand the limitations of the different methods of assessment. IT interviewers are put in a almost impossible situation, they need to test a candidates knowledge, but they have no way to review their actual work history (the only thing that actually does correlate to success) so they are left grasping at straws.

Re:Focus on a few key things

[ShanghaiBill]

Great list! However you missed the one quintessential CS book.

Godel, Escher, Bach: An Eternal Golden Braid

Actually, I didn't miss it. GEB used to be on my list. But I removed it. To really appreciate the book, you need to already have a foundational knowledge of completeness, recursion, complexity, emergent phenomena, etc. But it isn't such a good book for learning those topics in the first place. Non-tech people can enjoy reading the book while not even realizing how much is whoosing over their head.

Re:Focus on a few key things

[Anonymous Coward]

If you're requiring them to do it, that doesn't really count as on their own time. More like unpaid labor. But hey, that's the norm in this chump "profession".

Re:Focus on a few key things

[Anonymous Coward]

Would you hire someone that cannot solve that in 20 minutes?

Yes. And I'd demote the narrow-minded puzzle geek who thought that was a good interview question.

Re:Focus on a few key things

[JaredOfEuropa]

I've read a fair few of those books; this is a great list for self-taught programmers, and I certainly include myself in that category

But one thing I often find lacking in both amateur programmers and coders with a formal education is the skills to do OO properly. These days most of them know the basics: class vs instance, abstract classes, inheritance and overloading etc, but what's missing is the knowledge and skill to design a good object model. In an OOP course I did years ago, students were given the books "Design Patterns" and "Anti-patterns", which were useful to teach common OO patterns and to promote thinking in patterns, but it doesn't cover object modelling as a whole. If anyone knows of a seminal work on the subject, I think it belongs on this list.

Re:Focus on a few key things

[Anonymous Coward]

Would you hire someone that cannot solve that in 20 minutes?

Here is my daughter's solution:

I'm not sure I'd hire your daughter. :) Fundamentally, these toy problems tend to be massively under-specified.

Let's say I'm working on a scientific application and I have to know the answer to that question, well I'd go for a much simpler implementation that was less likely to have errors - run it once and save the answer.

On the other hand, let's say I need a general algorithm that could calculate this answer for other ranges of input numbers. Well, in that case, her implementation has all kinds of problems - everything from numerical overflow to quadratic time complexity.

But let's say I don't really care about the algorithm, per se, and just care about the general quality of the code. In general, I'd like to see more descriptive variable names and better comments. For example, she seems to be assuming that there's at least one palindromic number in the set she's testing. That's a reasonable assumption but if you're writing code that guaranteed to be correct you don't want to just blindly return zero - at least add a comment as to what you're thinking. Also, the "speed up" line really needs some comments, for example, would 10 (which could be represented as "010" if leading zeros are allowed) count as a palindromic number? What are the input ranges where this speed up is valid?

Long, story short, your daughter's code is something I would hate to see in professional production code because, if I suspected there might be a bug in it, it would take me a non-trivial amount of time to figure out what she was thinking when she wrote it and what all her assumptions were.

Good programming is about showing how clever you are at finding simple solutions to hard problems but this looks more like a case of showing how clever you are by finding an unnecessarily complicated solution to a simple problem.

Re:Focus on a few key things

[JaredOfEuropa]

To be fair, you do it for both. Most companies expect their professionals to stay current in their field and further develop their skills, and the good ones provide at least some help in doing so: training (on the company time & dime), a book budget, 2 hours a week of study time, help getting certified in relevant areas of expertise, etc.

Re:Focus on a few key things

[Anonymous Coward]

Here is my daughter's solution:

As a professional programmer in the sense that it's my day job, lines like this in production code make me shudder:

max = 0
b0 = max // a

Presumably it's a crude attempt at optimization. But it has the implicit assumption that there's at least one palindromic number in the input range. The first time through the loop it starts at zero and generates palindromic numbers that are the product of one, two, and three digit numbers. At a bare minimum this should be commented. But it's also a heuristic optimization that makes certain assumptions about the density of the palindromic numbers. Again, this should be commented.

In a certain sense, it's an example of exactly the kind of errors that novice programmers make. Rather than providing a clean simple implementation of what was specified, your daughter tried to add a bit of flare and introduced some bugs with her optimizations. One of the key rules of professional programming is that if you're going to add unnecessary optimization then it had better be crystal clear that you're not breaking the specification.

Re:Focus on a few key things

[JaredOfEuropa]

While I don't endorse the tone, I do agree somewhat with the sentiment of this. Depending on your field and your location, it can be very hard to find a job as a 45+ year old professional, and not just in IT: there's a few other professions which are not in hot demand right now, with a lot of older experienced people looking for jobs. It may be somewhat true that people with extensive professional networks always get hired, but that certainly doesn't equate to "the good ones will always find work", and by extension "it's your own fault if you can't find any work"

until social scum like you forced the socially awkward out of the industry which they built for you

I'd say that the industry has evolved beyond the basement dwelling coder; social skills are more important in IT these days, and the industry is better for it. But now that there are fewer job openings, employers get to be more picky, and they don't always select on the right criteria. A strong emphasis on social skills where they aren't needed, for example. Or just hiring the most likable of qualifying candidates. Add to that the widespread notion that programming is a young man's game, that good programmers always move on to do other stuff at some point, that you're a loser dinosaur if you're still coding past your 30s. I recently had a chat with some ex-colleagues about hiring practices, and I got the impression that their companies are looking for people who are either college graduates, or experienced programmers who at the very least have developed and launched a wildly successful new OS or social media service. But a middle aged coder who is "merely" very good is suspect: why isn't he an architect or a project manager?

Re:Focus on a few key things

[Sesostris III]

Out of (not so idle) curiosity, what is the complete list?

Re:Focus on a few key things

[No Longer an AC]

If they say the book was good, they didn't actually read it.

Okay, I only read one of those books and while it was informative I didn't like it.

Re:Focus on a few key things

[LesFerg]

By the time someone is 40-50, they should have a broad skillset, and a deep network of former colleagues. The old guys whining about being unable to find a job are mostly turds that have serially rejected and their former co-workers are glad to be rid of them. There are a LOT of people like that out there. These are the guys you remember from college who wanted to copy your assignment an hour before it was due, because they had no idea how to do it themselves, the dead weight on your programming team, and now they are old.

Condescending asshole, you're forgetting about the entire generation of socially awkward nerds whose childhood coincided with the personal computer revolution, who grew up interacting with machines instead of people, who never learned social skills, and who never accumulated a professional network because they'd rather not interact with people like you. Those were the technically inclined kids who were doing all your programming assignments while you dead weight bastard cheated your way through college. Those nerd kids grew up, and they're literally 40-year-old virgins now. Until recently they were able to make a decent living using only their technical skills, until social scum like you forced the socially awkward out of the industry which they built for you.

I agree with most of that, tho also I have the problem that most of my network of former colleagues have retired or died. Guess I could have moved on to managing other developers but I didn't enjoy that, and stuck with doing what does give me reward.

Re:Focus on a few key things

[LesFerg]

But a middle aged coder who is "merely" very good is suspect: why isn't he an architect or a project manager?

For me, I started out in small companies where I was doing a bit of everything, so the title didn't include architect etc, but I had projects that were challenging and fun, and I just got in there and did them. Later on when I started looking round for another job, I had piss all to prove what I had done or what I knew, and had a bunch of young quiz masters trying determine if I knew something, but I couldn't tell what it was they were looking for, it certainly didn't relate to the decades of experience I have behind me, and it seems I'm just an ass when it comes to those interviews. Never mind, do my own thing I guess...

Re: Focus on a few key things

[Anonymous Coward]

1. Write unit tests
2. Write unoptimized, clear version that passes all tests
3. You're probably done
4. Wait, this shit runs in O(n^fuck)
5. Write even more unit tests
6. Optimize

Re:Focus on a few key things

[Registered Coward v2]

My company hires many young non-degreed self-taught programmers (because that is all we can find). We give them a reading list, and require them to spend about four hours per week doing professional reading and studying on their own time.

While your approach has merit it would seem your company is setting itself up for a lawsuit over unpaid wages, unless the new hires are truly exempt employees.

Re:Focus on a few key things

[Registered Coward v2]

I would add: The Power of Habit: Why We Do What We Do in Life and Business. This gets you started thinking about why people do things a certain way, and if you do interface design you should think about how your interface will be used and what triggers actions.

Re:Focus on a few key things

[Applehu Akbar]

"spacecraft costing 300 million euro and up. If I ever fuck up I guarantee you _will_ read about it here on slashdot. "

And if your EUR 300M spacecraft reaches its goal, and accomplishes wondrous things there, but you happen to be wearing the wrong shirt at the press conference, you will be hearing from Huffington Post forever.

Re:Focus on a few key things

[Applehu Akbar]

I blame the puzzle-question job interviews for the rich variety of clever code out there that is hidden behind horrible user interfaces.

Re:Focus on a few key things

[tommeke100]

I checked out that Euler site to see what type of problems there were and I'd like to see the average 14 year using tricks to solve geometric progressions and such, which was clearly something that was necessary on the first random problem I looked at.

Re:Focus on a few key things

[Wescotte]

Just having a suggested reading list sounds amazing to me! I've unfortunately never worked for a company I thought put continuous effort into training their employees to be more effective. It seems like the only employee benefit I've never had from a job... Are you hiring now?

I'm self taught but went back to school after a ten year absence and got my CS degree. I recently left my current employer because they were too willing to hire under-qualified candidates (myself included) without having a good support system in place to train them. I don't necessarily mind being in that position as I'm willing to learn on my own and it definitely keeps things interesting but this place took it too far. We're talking hiring somebody to do data entry who types by hunt and peck and then a manager not requiring them to learn. I can understand not sending them to a class during office hours but how can you justify not even picking up a copy of Mavis Beacon and requiring the employee use it.

Everybody worked insane hours flying by the seat of their pants, not because they had to but because that's just what happens in this type of environment. Steady overtime was great for putting a dent in the student loans but I could only take it for so long.

Re:Focus on a few key things

[Bongo]

I gather the notion of design patterns came from an architect (buildings) who visited Italian towns to try to find out why they "worked". In other words, he was trying to learn from established experience. And the film director Ridley Scott said that the voice of experience is what he calls intuition. In a way it is the opposite of math puzzles. It's having enough experience in organising things that you start to intuitively foresee that some arrangements will turn out more simple and elegant and maintainable.

Re:Focus on a few key things

[Anonymous Coward]

If they answer it correctly you don't really learn much about them, but if they can't answer it then you learn all you need to know. It means they are dumb as a post if they can't figure out the obvious brute force solution. People who can't solve simple puzzles are not intelligent. Everyone moaning about puzzles keeping them out of jobs in software are people who think they are intelligent, but are wrong. The main thing I look for in a candidate is whether they *like* solving puzzles. Do they get a nice shot of dopamine in their brain when they solve a puzzle? Are they motivated to solve problems? What that tells me is that they will enjoy the work versus hate it. Hiring someone who will hate their job is bad for everyone. People who hate puzzle questions shouldn't work in software, they should work in data entry. If they want to be paid to type they should be typists. If they want to be paid to *think* then they should be good at it and enjoy it and welcome puzzle questions in interviews.

Re: Focus on a few key things

[Anonymous Coward]

Maybe you should have spent more time mentoring young programmers than yelling at them to get off your lawn.

Re:Focus on a few key things

[phantomfive]

Which one?

Re: Focus on a few key things

[Anonymous Coward]

So the opposite of college then? Where everybody just wings it, patiently waits until Thursday because that's when the weekend starts for college kids.

Re: Focus on a few key things

[Anonymous Coward]

That one.

Re: Focus on a few key things

[Anonymous Coward]

Now that I've said this I can cry myself to sleep

Re:Focus on a few key things

[Waccoon]

Given that they're required to do unpaid homework on their own time, I'd assume the answer is "yes."

Re:Focus on a few key things

[Anonymous Coward]

Main as the only function in python?

I wouldn't hire her. She doesn't know how to leverage language, only rote reasoning- not unlike how most view math. Leveraging the benefits of each language is something that professional programmers do.

Keep on hiring the uneducated and unaware. Good job security to fix all those bugs.

Re: Focus on a few key things

[Anonymous Coward]

And then, there are the guys like me. 36. C++ since day one, you name it, I've done it, in c++.

But, we spot people like you, and avoid working in such environments.

Then again, if your company was any good you wouldn't be in godforsaken backwaters in the first place.

Things balance out in this universe.

Re:Focus on a few key things

[Anonymous Coward]

The books include "Clean Code", "Programming Pearls", "The Pragmatic Programmer", several books on algorithms, code complexity, and books on software engineering such as "The Mythical Man-Month" and "Joel on Software".

Thank you for listing some of them. I have Clean Code and try to do a fair amount of reading. I don't suppose you could provide a short list of the some of the others?

I don't have a CS degree but I've been working as a developer for quite a few years. I've been assured by many with BS and MS degrees on the subject that school doesn't provide students with most of what we're talking about, so I haven't been too terribly motivated to go back to school. I do, however, try to improve on my own... so thanks!

Re:Focus on a few key things

[dwpro]

Is the salary/salary range on the job posting? I find it hard to believe you don't get enough qualified applicants with a decent salary range, we've never had a shortage of qualified applicants in Austin, TX or Oklahoma City, OK.

Re: Focus on a few key things

[Anonymous Coward]

Shanghai Bill, complaining about his terrible staff and his lack of success in business management, recruitment and hiring.

Must be the employees fault though.

Can't hire skilled people, can't cite wages, location and skill needs, can't post a url... But can bitch about not being able to find qualified talent in an online post.

Re:Focus on a few key things

[superwiz]

There has been numerous studies done showing that these types of things don't correlate.

Citation, please? Not being obnoxious. I am honestly curious to see a formal study.

Re:Focus on a few key things

[superwiz]

Yet somehow I have _never_ needed to determine if a number is prime, or indeed any of the other circus tricks at Project Euler.

There is a difference between writing low-level library code and application code. Understanding optimal strategies of handling integers very often ends up being an exercise in rudimentary number theory. That makes it useful when figuring out an optimal hashing function, knowing when worse big-O solution will give better real-world performance results because of the real-world boundaries on your number, etc. You are at the very opposite end of the spectrum. Your solutions are heavy on unique situations and light on the number of users. Someone who writes code to be used by other people (a custom db-engine, for example) would have to write code which is light on setting operational boundaries and heavy on number of use-cases. So they would need to think through how performance would change as the boundaries of the problem domain change (because they don't know what their users will need). That's pretty numerical in nature. There is also a whole class of problems which grow in computation time very quickly if you don't cull unnecessary operations. Try something simple for size. What's the big-O size of a common-law legal system? You don't think that's a math problem? Most of breaking-down of programming into tasks is actually a Galois correspondence. Ok, you don't need to know that to code, but if you do know what comes with it, you can't break out of the paradigm of "how things are" and into "how they should be" given a different problem domain and nudge your code in that direction. Shorter story? If you want code optimized for one problem domain, you don't need much math. If you want to hop from one problem domain to another often, you do.

Re: Focus on a few key things

[Anonymous Coward]

Why is she searching upwards ? To find the largest palindrome in that range, start with 999 Ã-- 999 and search downwards.

Re:Focus on a few key things

[ShanghaiBill]

I blame the puzzle-question job interviews for the rich variety of clever code out there

This is not a "puzzle-question". It is a simple and clear problem with an obvious solution: A nested loop with a comparison, that can be done with either strings or mathematically digit by digit. The only question is whether you have the coding skills to turn a one sentence spec into 10 lines of code. Most programmers can. A surprising number cannot.

Would I hire someone who can solve this problem? Maybe. Maybe not.
Would I hire someone who cannot solve this problem? Absolutely not.

Re:Focus on a few key things

[shmlco]

If you give someone Clean Code then at some point it's going to be pretty obvious during code review whether or not they read the book.

Re:Focus on a few key things

[shmlco]

I take exception to the expectation that they're supposed to complete a company assignment on their own time. Where I work now they tend to run a "book club" where once a week the current group gets together and discusses the latest chapter or so, asks or answers question, and a moderator/mentor is often present to explain why we do what was discussed.

(Or why, after consideration, we decided NOT to do that...)

Re:Focus on a few key things

[ShanghaiBill]

I'd like to see the average 14 year using tricks to solve geometric progressions

In California, exponents and geometric progressions are taught in 6th grade. So I don't know why you think a 9th grader wouldn't know about them.

which was clearly something that was necessary on the first random problem I looked at.

Which problem was that?

Re:Focus on a few key things

[superwiz]

Most actual coding challenges use project Euler problems as starting point and then scale the problem. Although some of the later project Euler problems are difficult in their own right. But any one of them can be made difficult if you expand the boundaries and narrow the restrictions. It almost immediately becomes a test of not only knowing which optimal algorithms exist, but whether you can apply them to solve problems.

Re:Focus on a few key things

[shmlco]

Essentially, you weed out the qualified applicants by giving them math problems involving Fibonacci sequences and quadratic equations.

You know, the kind of stuff that I as an iOS developer doing banking apps talking to OAuth2 services and JSON backends databases do daily.

I "might" do this sort of thing if I was hiring and had someone in front of me with no sample code, OSS contributions, side-projects, or apps to their credit... but using it to weed out initial candidates... even those with the above credentials... is just stupid.

And it's ESPECIALLY stupid if those problems are not indicative of the problems they're going to be solving if they're hired.

If, say, your employee is going to be developing apps that move information from an endpoint to a screen on the app, letting the user fill it out, and then submitting validated data, then why by god don't you give them that sort of problem? Give them an API endpoint, a spec, some credentials, and tell 'em to come back in tomorrow with a demo app that works. Then code review the projects.

Extra points for proper validation techniques, clean code, use of a git repo, proper error checking, and so on. Bonus points for a clean UI design, use of modern techniques like RFP or MVVM, assistive, localized interface design, and so on.

You might find more of the "qualified" candidates that can do the work you need as opposed to just those skilled at answering puzzle questions on the fly.

Re:Focus on a few key things

[Anonymous Coward]

A couple other suggestions:

About Face by Alan Cooper (half is outstanding, half is a little preachy)

Waltzing with Bears (all about risk)

Re:Focus on a few key things

[WDot]

Well I can't upvote this, but I just wanted to say that I'm adding this list to my to-read list. Some of it is already familiar to me but there's a lot of gaps I'd like to fill!

Re:Focus on a few key things

[Anonymous Coward]

A mind for numbers by Barbara Oakley. Lots of learning strategies, explanation how the brain works, etc. Wish I knew that at 20.
Oh, and why is your list missign the Knuth? Of course, no one reads the Knuth back to back, but just knowing that there is someone out there who really thought things through gives you a whole other perspective on things...

Re:Focus on a few key things

[shmlco]

As I mentioned above, If your employee is going to be developing apps that move information from an endpoint to a screen on the app, letting the user fill it out, and then submitting validated data, then give them that sort of problem. Give them an API endpoint, a spec, some credentials, and tell 'em to come back in tomorrow with a demo app that works. Then code review the projects.

Extra points for proper validation techniques, clean code, use of a git repo, proper error checking, and so on. Bonus points for a clean UI design, use of modern techniques like RFP or MVVM, assistive, localized interface design, and so on.

Then if they pass the code review, hire them on a 3-month probationary basis to see if they meld well with your culture and teams.

Re:Focus on a few key things

[Anonymous Coward]

I think the issue is the one size fits all approach to the hiring process and interview questions. Having a strong knowledge of algorithms, trees, and graphs, and discrete math in general may mean a lot more if you're building some complex 3d game from the ground up or something like Google Maps, but has very little if any importance to most mobile and web developers. Someone could ace that part of the interview while not knowing shit about popular web stacks or how to develop for iOS or Android. Of course, they still need to have problem solving skills, but that's tricky to determine through some pop whiteboard questions, especially if you're pulling random shit off of Project Euler or random obscure problems with 10% success rates from some competitive coding type website.

Re:Focus on a few key things

[Xest]

Have you read these books yourself out of interest?

I ask because I looked over The Pragmatic Programmer again myself a year or two ago and was horrified at how poorly it's aged. Some of what it professes is frankly just outright bad practice nowadays so if you haven't re-evaluated it I'd suggest scrapping it from your required reading list.

Re:Focus on a few key things

[Anonymous Coward]

rapid development by steve mcconnell should imho be required reading

Re:Focus on a few key things

[Anonymous Coward]

That is a really bad presumption. I give every interviewee a random problem from ProjectEuler [projecteuler.net]. I am amazed at 40-50 year old "professional programmers" that can't come up with a solution. My 14 year old daughter has done over 100 of them, typically in about 20 minutes each.

You've now confirmed my "you have to be like me" theory of interviews. You're the algorithm/puzzle guy that thinks everyone in coding loves these dumb puzzles. Some do, the rest of us loathe people such as yourself who think of the world in a narrow way that must reflect YOUR skills and interests.

It's great if that's actually what you wind up doing, but I totally agree with the guy below, that never in my 20 year career have I needed to figure out if a number was prime or not. Not all programming is these silly alogorithm/puzzle things where you implement some silly sorting algorithm, or try to figure out how to figure out when the glass ball breaks in the least number of drops. It's fun that you're into that kind of thing, but please, for the love of god stop assuming everyone else is.

Re:Focus on a few key things

[Gaby de Wilde]

I think that proves she is not your daughter.

Re: Focus on a few key things

[Anonymous Coward]

If you search downwards you still have to do a brute search. If you return early you will get 995 * 583 = 580085. The correct answer is 993 * 913 = 906609. Of course you can check at the top of the inner loop if it is possible for the multiple to be larger than the previous answer you can speed this up.

Personally I think I would start with 997799, the largest six digit number that could possibly be divisible by two 3 digit numbers (has to be less than 999 * 999 = 998001) and then check 996699, 995599... this would run in O(n) as opposed to O(n^2). Of course this requires a good factoring algorithm but if you are using python you can pretend.

Re:Focus on a few key things

[dougg76]

Your right, this is a good question. Most of the studies I am referring to were those that were brought up when I was studying math education year ago and I no longer have access to an actual research databases. The studies subjects covered how testing and actual math proficiency are ambiguous, how GPA and SAT scores don't strongly correlate with success etc. It is very hard to find actual information specific to IT proving one way or the other. There have been interviews with google HR about https://techcrunch.com/2013/06... , but this is not a study but just semi anecdotal head scratching.

However, with a cursory understanding of pedagogy, the dangerous assumptions that are made in many tech interviews are blatantly obvious. Creating meaningful test is a very hard thing to do, maybe even impossible; It just rubs me the wrong way how people in IT are so sure of something they know so little about. It really should not be up to unqualified employers to vet the education or life experiences of a professional, we really need a sort of accrediting body to develop a more meaningful baseline.

These technical interviews always give me the silly image of some manager throwing a engineer a bunch of toothpicks and tape and then with a serious face, asking them to build a bridge; It would be considered ridiculous in any other field.

I am also not being obnoxious, but are there any studies that help clear up what does work? There has to be formal work on this somewhere.

Re:Focus on a few key things

[Anonymous Coward]

you're a loser dinosaur if you're still coding past your 30s

This line really struck me last night and had to reply to you in the morning.

Is becoming a software developer this bad? I really don't want to think it can be this bad compared to other professions out there. What's wrong with coding past your thirties and why is it seen so in negative eyes? Life/work expectancy of a software developer is 21-30? One decade of software experience and you're done?

It's frighten me as I'm currently 26 year old and trying to enter the software development field. I'm a graduate in Mechanical but so far the job opportunities available, they don't really interest me. Very mundane and nothing new in it. The only way to try out new cool things and getting involved in is software development.

In other words, only five years of coding life I have left before seen as someone 'too old to be doing this"? What do software developers do after age 30? Do they switch to some other field like project manager or something? I know some people code since high school but I never been able to have that opportunity. Actually more like I never met anyone who was that into computers and sort of guide me. It's only now when I'm seriously thinking about my future, software development comes to my eyes.

Re: Focus on a few key things

[Anonymous Coward]

There is only one way out of misery now

You mean move to Vietnam and have a good life?

Re:Focus on a few key things

[Anonymous Coward]

I've worked with a lot of puzzle geeks. Always chump employees - sorry broham, no consulting for puzzle geeks. Sometimes decent people. Sometimes clever programmers. But very rarely good programmers.

Re:Focus on a few key things

[ausekilis]

One of my undergrad Prof's had "Define, Defend, Attack" questions on his exams. His thinking was that to truly know something well, you have to be able to do all three. I found it incredibly useful to be able to explain something to someone else, too. I would think it would be pretty simple, hopefully not too time consuming, for the resident grey-beard to ask a question of them.

"Multiple Inheritance is the notion that one class can inherit from more than one parent class. A pen can be both a "writer" and a "cylinder". It's useful when the data encapsulation and functions make sense, but breaks down quickly when you inherit from two things that themselves have the same parent (diamond inheritance)"

Re:Focus on a few key things

[Anonymous Coward]

Yes, I realize I am critiquing a 9th grader's coding skills, but I've never used python so....
Let's run down the list of what's wrong here:

1) list isn't being used
2) b initially iterates over 0-99 uselessly, instead of starting at 100
3) the "speed up" incorrectly skips anything less than 100000. 101*101 = 10201 won't ever be evaluated, for example.
4) there's no point in forward iterating anyways, better to start at the end and work backwards and stop once you've hit the largest possible value

I'd say point 2 and 3 are probably the most egregious as if the answer exists between 10000-99999 it would be missed or if 0-99 yielded a valid answer (that for some reason was the maximum, perhaps different requirements) the output would be incorrect.

Re:Focus on a few key things

[Quirkz]

Hadn't heard of Project Euler before, but it seems nifty. I've been meaning to practice in a new language, and was looking for a source of mini-projects to work on. That seems like it may be a good source of ideas.

Glancing through the first page of the archives, all the ones I saw seemed pretty approachable. Just out of curiosity I jumped into the 400's, and I'll admit I couldn't even tell what the question was asking me to do. Presumably if done in order they'd make sense (acquired vocabulary, notation) but there does seem to be a learning curve.

Re:Focus on a few key things

[david_thornley]

I have removed the Mythical Man-Month from my recommendations. There's chapters that are irrelevant because of some technical advances. There's stuff it gets wrong (for example, it comes out fully against information hiding and for tight coupling). There's a lot of stuff in there that has been absorbed into common wisdom. There's still good stuff that hasn't been assimilated, but picking it out is going to be difficult for people who don't know it already.

Re:Focus on a few key things

[Anonymous Coward]

As a programmer, you should be able to fix the inefficiencies in your process. Instead of requiring everyone to buy those books, the company could have bought 1 or 2 copies and let everyone borrow them. Then you'd know who read what, would reduce the time spent for employees to find the books, reduce the employee's costs while adding a rounding error to your costs, cut out the shipping time, and have the books on-hand at work in case someone wanted to reference something.

Your company is also extremely cheap in requiring work that benefits the company but not paying for it. If I worked for you, I'd have no loyalty because you guys have less than no loyalty to your employees by requiring extra, unpaid work. Training is something good companies provide for free. It benefits everyone involved. And for the idiots who say employees will simply switch jobs after getting better, why do you want bad programmers working for you?

If you can't find college graduates, maybe you should attend college career fairs and visit on-campus clubs. Students love free food and interesting swag. Oh wait, you're hiring people out of high school so you're likely severely underpaying them and they'll have no reference so they won't notice. Inexperienced workers always make the best slaves. What to counter that argument? Name your company.

Re:Focus on a few key things

[phantomfive]

Domain Driven Design does a good job of that, imho. Long read, though.

Re:Focus on a few key things

[Anonymous Coward]

One of my favorite books is The Tao of Programming, although I read it longer than ten years ago.
Another I would suggest Zero Bugs and Program Faster.

Re:Focus on a few key things

[Anonymous Coward]

"Networking" boils down to kissing asses to get jobs. It's 100% wetware, and superfluous to any serious work.

Re:Focus on a few key things

[Anonymous Coward]

if we're looking for max, why not start at the ends and stop at the first one.

Re:Focus on a few key things

[John Bokma]

Touch of Class? Still haven't read it myself, hence the ?

Re:Focus on a few key things

[LienRag]

How come that you can commandeer their free time?

Re:Focus on a few key things

[SessionExpired]

This is why I keep reading slashdot. Thanks!

Re:Focus on a few key things

[Hognoxious]

I have a dead-tree version of it. Care to point out which bits are wrong, apart from the bit where it omits to tell you to grow a ridiculous beard and ride a fixie?

spend more time reading code than writing

[Anonymous Coward]

Find some good source code for them to study

Re:spend more time reading code than writing

[Z00L00K]

Then give them a part to work on and tell them to break it down into pieces no larger than about 40 to 50 rows, let them also write code that tests their code so that they can explain what each piece do.

Today the tools for maintaining code are a lot better than what many of us suffered in the 80's. If we were lucky it was 'vi', not 'vim'. Or on other platforms like OpenVMS it was "EDIT /EDT". A few here may remember EDLIN from DOS. Then realize that in the beginning programmers coded on punch cards that had to be loaded in correct order. Darn the person who dropped the box of cards and had to sort them out in the right order.

The programming environments today are good at detecting coding errors on the fly before compiling as well as offering ability to refactor code with ease.

Re:spend more time reading code than writing

[angel'o'sphere]

Darn the person who dropped the box of cards and had to sort them out in the right order.
For thar you have a card sorter, later computers sorted the cards first anyway, and depending on your punch card system, you can easily sort them with a knitting needle.

Re:spend more time reading code than writing

[Anonymous Coward]

Ah, you got to use the new fangled punch cards ;-) They weren't always like that.

Re:spend more time reading code than writing

[baegucb]

Punched cards on an IBM mainframe computer, way back when, usually had sequence numbers in the last 8 columns. So if I dropped my program, I just had to put them back in order by using the numbers.
And vi was way better than edlin as an editor. Using edlin as an editor in DOS sucked. You could write an assembler program in it but the program was limited to 64k iirc, but that was long, long ago.

Re:spend more time reading code than writing

[etrusco]

Perfectly said!

Re:spend more time reading code than writing

[Anonymous Coward]

You take a magic marker and draw a diagonal line across the top of the cards so that when you drop them you can see where each card is supposed to be.

Sometimes you can't

[Anonymous Coward]

I've seen a novice programmer produce quite good code. I've also seen a seasoned developer produce code that could only come from a novice.

Teach them to have pride in their work, and do things well or not do them at all.

Re:Sometimes you can't

[Anonymous Coward]

Teach them that their code is for other people. Other people to use, other people to maintain, other people to revise, other people to finish if they get hit by a bus. Be nice to those other people: explain your data structures, explain why code segments exist and what they're supposed to do. Work with a version control system and explain why commits are made.

Few novice/amateur programmers have had the experience of picking up one of their own programs, after they've forgotten it, to fix or expand, let alone trying to do the same with someone else's code. If it's easier to rewrite from scratch than to modify, then either the original programmer or the reviser is incompetent

Re:Sometimes you can't

[LesFerg]

Teach them to have pride in their work, and do things well or not do them at all.

One important aspect of coding that gets too little attention these days is, imagine if you were employed by the same company for many years, and had to go back and revisit your code from a year or more back, to make enhancements or whatever. Did you make code that you yourself could understand quickly, 12 months after you wrote it?

You may work in a team who have set some basic rules and standards for code, but even within those boundaries you can make code easy or hard to understand. Think of your future self.

Engineering is engineering

[Anonymous Coward]

Unless you start with a very clear definition of what it is that you want to create and the tools and techniques you will use to bring that definition to fruition you are merely hacking, hoping to end up with something that might work. There is nothing magical about decomposing a product definition into achievable, testable and verifiable requirements, but if you lack the discipline to do those things up front your odds of failure increase exponentially.

First things first

[Anonymous Coward]

Your first step needs to be to define "Professional".
Coding standards and best practices vary from company to company and industry to industry.
On the other hand, patterns of thought, like "Think about side effects", carry over, but are frequently too broad to teach in concrete examples.
And stuff like "Show up to work on time, sober and dressed", essential for the professional, shouldn't be taught in classrooms.

Re:First things first

[Anonymous Coward]

Perhaps we should do away with pointless dress codes, especially the ones with dependencies on 14th century fashion.

Re:First things first

[Anonymous Coward]

Pointless dress codes like ripped jeans and t-shirts with Mr Piccolo on the front? I'm all for that.

Re:First things first

[tburkhol]

And stuff like "Show up to work on time, sober and dressed", essential for the professional, shouldn't be taught in classrooms.

And yet, this is a component of almost every professional training program - ask your nurse, physical therapist, or pharmacist whether their program included 'professional presentation.'

Re: First things first

[Anonymous Coward]

Be careful about the way you phrase that question to someone with a needle in their hand...

Re:First things first

[Gaby de Wilde]

Lets get rid of physical locations in general. We had the telegraph in 1816, pneumatic tubes in 1836, a string telephone in 1667 and homing pigeons go back 3000+ years. I think it is safe to use the internet?

Re:First things first

[Gaby de Wilde]

Programmers should be more like construction workers and car mechanics.

Re:First things first

[Anonymous Coward]

> Programmers should be more like construction workers and car mechanics.

Grubby and grabby?

Poor

[Anrego]

Ideally, I want to give them some sort of practicals to do to articulate and demonstrate this, rather than just "present" stuff on best practices...

This raises the question of not only what you'd teach -- whether it's variable naming, modular programming, test-driven development, or the importance of commenting -- but also how you'd teach it.

I think this is already going down the wrong path. Those are just technical skills and practices that will be picked up over time, and some kind of workshop isn't really the place to learn them imo.

The important differences between a new guy and someone with a decent bit of professional experience under their belt isn't so much in technical skills or adherence to best practices, but it's more of a mindset and general direction thing. Once you've seen a few projects from start to completion, you start to recognize certain patterns and points where things can go really well or really bad. Once you've worked on a bunch of different teams, you start to recognize how different people contribute to a team dynamic and the various ways in which a team functions. You start to understand how your job integrates with the rest of our department and the rest of the business, how the whole management structure works, and what really drives most technical decisions (hint: technical merit is often the last thing driving a decision).

The problem is, you can't really teach that. So I guess my answer would really be very generic "how to be a good employee" type stuff: Take ownership of your problems, check your ego, play well with others, etc. Being a more professional programmer has little imo to do with being a better programmer and more to do with being a better professional. You become a more professional programmer by learning how to have a productive meeting with management about your project, not by learning the magic of continuous integration.

Re:Poor

[Aighearach]

I think the question is more like: What rubber chickens do I throw at the new people to make the snobby people feel better about letting in the barbarians?

Re:Poor

[Darinbob]

What I want is the experienced programmers to actually act like experienced programmers! Too many self taught people with EE or physics background with absolutely atrocious coding skills, no concept of algorithms, and an attitude that quick and dirty is the proper way to do things. I can't believe how some people manage to get an advanced degree without possessing any analytical skills.

At least novices can be trained.

Re:Poor

[Anrego]

I think this partly falls on the people leading a technical project. Yes, programmers should take initiative to produce the best code they can, and many do, but people have a tendency to the path of least resistance, and even when they are legitimately trying, they may lack the experience to intuitively know that what they are producing is sub-par.

Good technical leadership sets _and enforces_ standards. This should happen at every level, with the quality of the standards increasing as the experience of the people driving them increases. If someone produces sub part work, it should get kicked back to them to fix and re-submit. This is a hard sell for management because they see money and time being spent re-doing stuff that "works fine" during the initial learning period, but if you set the bar early and make it clear what will and won't be accepted, people will rise to it (or demonstrate that they are unsuitable for the role they are in).

Re:Poor

[Darinbob]

Some of these people ARE the leaders. They become leaders because they have work experience, or because because they've been at the company the longest, or because they're the only person working on a key piece of the project that no one else knows. (ie, someone understands radio so they get put in charge of doing the radio code, or they were the person who wrote all the unintelligible code back when the company was a startup and now they're senior lead in charge of screwing it up)

Re:Poor

[Anrego]

These are management problems and are way deeper than programmers producing shitty code. Unfortunately they arn't that uncommon.

Re:Poor

[AmiMoJo]

The most important thing is to make them realise that there are techniques and patterns to learn and that they are what separate the professionals from the amateurs.

To that end some introductory stuff about things like variable naming and code organisation could be really helpful. Give them a starting point and enough to see the value in studying it further.

Invert it

[PhrostyMcByte]

Start with some practical code/app samples that demonstrate clear trouble. Ask them to participate -- see if they can solve the trouble. Then show how the original dev got themselves into that trouble, and the "professional" thing you would have applied to avoid it.

Bonus points for going comedic with examples that are ridiculous to the extreme.

Re:Invert it

[kbrannen]

I agree on the examples and discussion around them.

I taught a class for some new programmers fairly recently out of school. They knew PHP and a few other languages, so they could do basic coding. However, we needed them to know Perl and our app.

I taught 5 classes of 1 hour each, 2 every week. There was about 20 minutes of lecture up front to explain ideas beyond the basics, and they were encouraged to ask questions during that. I also gave them a problem to solve at end of the lessons to complete for next time. The homework at the beginning was solvable in 10-20 lines; the ones at the end took nearly 50 lines. The last ~40 minutes of a session was spent going over the homework and discussing it. Each person presented their answer for everyone to look at and were asked what they found hard to do and why and we talked about solutions with emphasis on the why.

Part of the reason it worked well was because I stressed there was not 1 definitive answer, not even mine ... a working program (without bugs :) was the goal -- however they got there (rule 1). Negative criticism wasn't allowed -- only constructive criticism (rule 2) -- and thankfully there were no issues with this. My usual teaching phrase was to say "a better way to have done the same thing was ___ because ___", and to remind them that in the end we paid them to write working code.

The discussion of the homework allowed them to see how others did it, I also showed my answer though I always went last. We also talked about ways to do it better with a large emphasis on why something was better, trade-offs, etc. I also did my best to point them in the direction of good habits: comments, testing, modularization, maintainability, etc. I also mentioned useful books, most of which have been mentioned by others.

If I ever had to teach something like this again, I believe I'd do it the same way. All of the class members gave me good feedback and said they liked the format.

An expensive whip

[Anonymous Coward]

It's important to get a good, sturdy whip to beat your employees with. A good whipping is the only way they'll learn.

Re: An expensive whip

[Anonymous Coward]

Best answer. I use a rod, myself. Before that the employees would slack off all the time, but with routine beatings, they are nose to the grindstone.

Make them read these books...

[djbckr]

Make them read at least some of these books.

you want someone to write it for you?

[Anonymous Coward]

You've written such a "course" or you're wanting examples or others to write it for you?

Let them see lots of good code

[phantomfive]

If they are new programmers, probably they need more than just programming skill, they need skill acting like a professional. The Clean Coder does a really good job with that.
For programming skill, I'm going to suggest Zero Bugs and Program Faster. That book tries to change the way people think about code.

On the practical side, there's no substitute for looking at good code. Assuming you're a good programmer, this would mean code review is one method. Have him review your code and find mistakes. He'll think he's trying to catch you, but he'll learn a lot doing it. Then you can review his code, too.

Another good mentoring technique is unit tests. They show you the kinds of things the programmer is thinking about when they test. So you can look over the tests in code review and say, "hey, you forgot to test this aspect." Ideally you'll want him/her to be thinking of every possible test case, even if he/she doesn't actually write out the test.

Another thing is to treat the younger person with respect. Sometimes if you say, "Oh you did that wrong" they will automatically assume, "he hates me" and put themselves in an adversarial stance, which is not helpful for anyone. Look for things that they do that you really respect, and point them out.

Re:Let them see lots of good code

[Bite The Pillow]

Most coders will read more than they write, especially if they forget their own code.

I learned a lot from MESS/MAME code, and I do almost 0 C today. But I remember how to write. Write, read someone else, and give feedback.

Clever one liners are neat, but almost always compile the same as using intermediate variables. One is easier to read and debug.

Re:Let them see lots of good code

[david_bonn]

Positive examples are good. So are negative ones. I'd recommend giving a novice ownership of a large, ugly, very messy, but heavily used hunk of software and have them "clean it up". The ones that don't kill themselves will become professional programmers.

Re:Let them see lots of good code

[muons]

There isn't enough time for mentoring in a large group for three hours. By all means have a handout with sites/articles and books. There are some good suggestions like Code Complete, but you don't have time for that either. Start out by reading this: 201 Principles of Software Development and put together a narrative on how to develop requirements, how tests are based on requirements, what makes a good developer, etc.

Re:Let them see lots of good code

[Anonymous Coward]

Assuming you're a good programmer, this would mean code review is one method. Have him review your code and find mistakes. He'll think he's trying to catch you, but he'll learn a lot doing it. Then you can review his code, too.

My current boss is very strict about code reviews. But he focuses on trivial things like going through and requiring that I make random changes to my variable names. It would be one thing if he actually set up some guidelines for everyone to use the same naming scheme for concepts that are common to the whole code base. But instead he just goes with his gut. Needless to say, there's no high level design or organization for the code base. It's a complex mess of spaghetti code. The thread of execution meanders randomly through the code base - usually passing the same point multiple times because it's multithreaded with a complex web of listeners that no one could possible understand.

Re:Let them see lots of good code

[phantomfive]

Just name every variable 'i.' If he complains, rename them all to 'codebase_lacks_organization.'

Re:Let them see lots of good code

[Anonymous Coward]

You have described much of my professional career. "Hey, here's a big pile of ugly code on a project that's about to fail. You have 3-5 months. See how well you can clean it up."

The best way to get a novice programmer up to speed as a good programmer is to have them work with a grumpy old programmer who can revoke any of their commits at will, for whatever reason -- so long as the grumpy old programmer explains their reasoning to the novice programmer and works with them to get it fixed. Tell the grumpy old programmer that you expect code from the novice programmer to be good enough for the grumpy old programmer to maintain.

Expect wails and gnashing of teeth.

Re:Let them see lots of good code

[Anonymous Coward]

this. teach them to build a state machine with no redundant bits.

have stopwatch.isRunning return this.start != null && this.end == null; instead of this.state == States.RUNNING, where state is set for each of start(), stop(), pause()

this applies to procedural/oop, functional, SQL, even HTML and CSS. fixing this at a high level would eliminate 90% of the complexity that causes the majority of our defects. I learned this by comparing the crap code I used to write with samples from folks like Larry, Linus, etc el.

Re:Let them see lots of good code

[Anonymous Coward]

The best book on professional programming is still Steve McConnell's "Code Complete".

Prepare for Change

[Anonymous Coward]

I think the main important topics can be derived from the first principal of preparing for change. Being a professions is all about having a system that works despite changing requirements, code and staff.

Version Control: A system for tracking change, and allowing comparisons against the past.

Encapsulation and abstraction: Design such that part of the system can change without effecting other parts. Focus on decision encapsulation: when you have to make a choice, try and minimize the cost of changing that decision: avoiding duplication, encapsulation, abstraction and modularity are tools for this, not goals withing themselves.

Testing: How to make sure your changes meet their goals, as well as how to make sure the changes don't break things.

Documentation: Makes it clear what the code is supposed to do, and when that changes.

Learning: The tools, code, and people are all changing. You must also know when you need to change. This means learn what the options are. Being a professions requires enough general knowledge to know when you should study the details. You workshop should state its goal as help starting this process, which will continue to feed on itself if the developer is dedicated to learning. Learning standard terminology is a good thing to do in this regard, since it makes it easy for the participants to research further if they need to (Ex: tell them what asymptotic complexity is, and when they might want to care and look it up, rather than how to compute it).

I'd emphasize asserts and fail fast and how they help detect inconsistencies, which is your job: hiding inconsistencies just makes your job worse.

I'd spend the end (or maybe more) of the session doing a code review to try and get people to spot areas for improvement in some provided code that aligns with what was covered during the rest of the session (bad/missing tests, needed docs, needless complexity, duplicated decisions etc). That will give people a chance to try and apply what they learned, and be shown cases they miss to let them know their personal weaknesses. be sure to discuss problems in terms of what problems they will cause (making future change difficult for example) rather than rules they violate (ex: duplication). Code review also replicates an important industry procedure that a lot of armatures don't have experience with.

Three hours?!

[glitch!]

Three hours won't do much for coding skills. Reading style(9) is a good idea. And so would be a few minutes on naming.

With the extreme constraints of the topic, I think a good topic would be proving code is correct. Talk about logical proof, and how it can often be very hard, and how to write software to verify that the code does not fail with normal input. And then, how to verify correct behavior against abnormal input. If coders would write software to attack their own code, I think they will benefit greatly.

Easy.

[Anonymous Coward]

Beatings.

What worked for me

[Snotnose]

No college degree, self taught Z80 assembler. Long story short, marketing found out I wrote space invaders for an 8080 based 1553 bus protocol analyzer. Took it to trade shows. Management found out, took me from tech to engineer. As an engineer I wrote code for various hardware. The rule was, when a bug came in you had to fix it. No matter how long ago it was, you owned it.

Quickly learned how to write good code that I could understand a year after release.

Re:What worked for me

[Anonymous Coward]

That was difficult like the pong game I wrote for Z80, but considering these days you need to know CSS, HTML, JavaScript, Java and SQL just to write a damn web form, things are much more difficult for young'uns.

Re:What worked for me

[ruir]

If you meant more difficult how to understand computers I do agree with you. If you meant more easier understand assembly....bah maybe easier for us, old timers that grew up with it. I even wrote one of the first open-source computer emulators for Windows, with the virtual Z80 CPU core all written by myself as my thesis.

Re:What worked for me

[sconeu]

Memories... I wrote a Z80 emulator as well for my job. We were doing development for the Litton Briefcase Terminal (AN/PYC-1) and Digital Communications Terminal (AN/PSC-2).

We were developing on a Unix host (originally ZILOG ZEUS for Z8000, then SysV68K for MC68030). We had Z80's as slave I/O processors. I wrote an emulator (that also emulated some of our custom hardware (such as hardware swap segments).

The good old days...

Re:What worked for me

[Rockoon]

If you meant more easier understand assembly....bah maybe easier for us, old timers that grew up with it.

The thing is, assembler isn't hard. Whats "hard" is knowing the architecture so that your code is efficient, which is a different thing entirely. Back in the day it was all about instruction cycle counts (latency.) These days its about instruction throughput, which execution units will be used, knowing what memory will still be in the caches, and so forth. Know your architecture.

The real problem is that "you dont need to know assembler" because "compilers are better than assembler programmers" is just a bullshit (its not true) excuse for C++ programmers to feel better about not knowing jack shit about the architecture that they are targeting.

An assembly language was either the 1st or 2nd language for most of the best coders in the world today

If you only learn C, you are a one trick pony. If you add in C++ to your repertoire then now you are a two trick pony. Those guys that know assembler are infinity-trick pony's. It may take them a week or two to get up to speed with a new language, but when they do they will be great, and you wont have to hold their hand even while they are learning the new language.

Re:What worked for me

[JustNiz]

>> An assembly language was either the 1st or 2nd
language for most of the best coders in the world today

The real reasons for those/us guys being good are nothing to do with what you said. Its simply because most of us that started that way are old enough that we have also picked up lots of other experience along the way, such as already having learnt a lot of what newbie engineers think is the hot new idea, because a functionally identical idea actually came round decades ago but just called something else.

Also, as an assembly programmer, you actually know a LOT more about how computers work at the lowest level such as register types, MMUs and DMA etc. I don't think they teach that stuff even in CS degrees any more. Most junior programmers have been brainwashed to program as if computer resources are effectively infinite, and to also drag in whole libraries of crap just to do some simple task. Haven't you ever wondered why even though computer power/size has scaled in factors in the last 30 years, many OS's and apps are still laggier than their functional equivalents of 20+ years ago?

>> Those guys that know assembler are infinity-trick pony's.

Not really true at all because as you pointed out yourself, the downside of assembler vs even compiled C is that you are very much locked to a single specific hardware/CPU architecture and even model.

Re:What worked for me

[david_thornley]

It was a lot easier to understand what went on. When I had Z80 computers, I knew what the CPU was doing and for how long. I knew how long it took to access a memory location.

Now that I have i5 computers, I don't know what the CPU is doing at any time, and I don't know how long it would take to access a memory location.

Re:What worked for me

[Rockoon]

Also, as an assembly programmer, you actually know a LOT more about how computers work at the lowest level such as register types, MMUs and DMA etc.

I didnt need so may words to say it. 3 fucking words. "Know your architecture."

I don't think they teach that stuff even in CS degrees any more.

Are you sure that they ever did? Computer Science isnt a programming course.

Most junior programmers have been brainwashed to program as if computer resources are effectively infinite, and to also drag in whole libraries of crap just to do some simple task

I also come from the day when a library was a collection of modules where only modules your code depended on were brought into your binary. However these days everything depends on the monolith. When languages first started using monoliths in the late 80's and early 90's (circa the rise of RAD), it was the assembly language programmers that "hacked" it with stub libraries that tricked the linker into not including the whole thing, with thousands of symbols all pointing to the same address containing a single return instruction. This has nothing to do with experience ("junior") and everything to do with doing stuff that can only be done with a module produced by an assembler. In all other languages symbols arent just symbols.

Re:What worked for me

[JustNiz]

>> I didnt need so may words to say it. 3 fucking words. "Know your architecture."
The way such stuff generally works is not architecture specific.

>> Are you sure that they ever did? Computer Science isnt a programming course.
Well they very much taught programming, good algorithm design etc and stuff like MMU internals, DMA etc when I did mine.

Talk about Specs

[Anonymous Coward]

Might be worthwhile to talk about the importance of using specs

As someone who has gone from dozens of projects that I never finished, to working on a professional level and writing production applications: the biggest piece of advice I wished someone had given younger me was the importance of writing a good functional spec (or at least adhering to one)

Maybe it's super obvious to everyone else or people who had the luxury of formal education (and ofc anyone who has read Joel Spolsky's classic blog series on specs) but writing a spec is damn near the most important step towards finishing a project in a predictable manner and avoiding scope creep.

Just my 2 cents..

That's good. How to learn, and why to learn

[raymorris]

> Teach them to have pride in their work, and do things well or not do them

With just three hours, if it's not three hours every month, I think this is on the right track. In limited time, you may get the best bang for the buck teaching them how (and why!) to learn rather than teaching technical details.

You can present things like code review (peer review) and automated tools that look for code smells. The dangers of stackoverflow.com and how to know which answers are good.

First, however, you need the WHY. Why should they write better code? Why should they care? I'm known for pointing out how much time and energy we spend "putting out fires" and suggesting instead that we fireproof things up front. I'm all about avoiding having pagers go off on the weekend.

People do things because a) they want to and b) they can. If you just present a skill or tool, they *can* use it, but they won't unless they *want* to. What pain they currently experience can be relieved by following your suggestions?

Re:That's good. How to learn, and why to learn

[Anonymous Coward]

What is this "pager" you speak of?

How to dig into big unknown codebases

[Anonymous Coward]

A topic I would mention is how to approach or structure fixing bugs or extending a large, established code base full of warts.

Re:How to dig into big unknown codebases

[Anonymous Coward]

Amateur. You don't "dig into" an established code base full of bugs. You run the beast through debuggers. GDB and Valgrind are your best friends. If you try to debug a large project by reading the code, you're an idiot.

Teach by example

[Anonymous Coward]

Find a lesser-quality open source project and discuss what improvements might be made to the structure and overall design decisions. Then have them implement them. Bonus: Have them or another group re-evaluate their work once it's done or when the curriculum ends. Best way to learn is to look at a lot of code.

Re:Teach by example

[Anonymous Coward]

No. Seek high profile open source projects and fork them on github. Push worthless commits like "fix whitespace" that contribute nothing of value. Fill your github profile with trendy shit. Be a totally fucking worthless rockstar coder.

Re: Teach by example

[Anonymous Coward]

Lame reply, nothing of value in so many pressed buttons.

Re: Teach by example

[Anonymous Coward]

Listen here, you. I'm tired of seeing "Couldn't load network graph. Too many forks to display." because a bunch of wannabe rockstar socialite cunts just have to fork all the latest trendy projects. I'm tired of seeing pull requests that touch every line of code because some moron wants street cred for changing the indentation. I'm tired of social coding because it's ALL social SHIT and NO fucking CODING.

Paper && Talk

[Anonymous Coward]

- Classroom discussions will help you get acquainted the new people and them with you & other employees. Written guidelines & practices can act as subject lines for discussion. You don't have to use existing SOPs. Keep it all light & flexible between each newcomer's briefing. Three hours should be sufficient time. Do not forget the coffee & donuts.

Mentors!

[Anonymous Coward]

Mentors can do far more than a book or course. Teach them to rely on successful mentors.

Professional or Competent

[SlithyMagister]

Professionalism is some mixture of attitude and effort.
If a programmer has a willing attitude, and puts in a good effort, the competence will come with time.

No matter how competent, a programmer whose attitude is lacking, or whose effort is lacking will hinder whatever project they're a part of.

As for building competence, I really liked "Code Complete"

Re:Professional or Competent

[meburke]

I would have brought up the distinction between "professional" and "competent" but someone beat me to it.

However, neither of these labels have a specific meaning. How do you know if a programmer is "competent"? It is easier to tell if a programmer is incompetent, but the line between the two states is fuzzy, particularly since the competency criteria depend on context such as specific languages, specific hardware, and purpose of the software. An assembly language programmer may be perfectly competent or even excellent in a robotics factory, yet be totally incapable of applying the requisite skills for accounting software where the development language is Java or C++.

And "professional" implies a common set of standards. This type of standardization is totally missing in programming field, which has retained its "craft industry" cachet for multiple generations.

If I were responsible for bringing up a new generation of programmers, I would spend a LOT of time identifying specific criteria, and then prioritizing those criteria before I even addressed the content and skills necessary.

Easy...

[Anonymous Coward]

Plop down a copy of McConnell's "Code Complete" and a copy of Martin's "The Clean Coder" in front of each of them and say to them (in your best Samuel L. Jackson voice) "Start reading, muthafuckaz!"

Real Life Experience

[Anonymous Coward]

First I would get them to support someone else's code. That would teach them the importance of logging.

Second I would get them to fix someone else's bugs. That would teach them the importance of testing before release.

Third I would get them to extend someone else's application. That would teach them the importance of modular programming.

Classes are great for learning some initial technical skill, but mastery is best learned through real-life experience.

Re:Real Life Experience

[Beeftopia]

Fixing someone else's code is a great way to learn how to write code. Not the algorithm, but the commenting and readability and maintainability.

Other things to make novices more professional:

1) Try and stick to "best practices". Things like "DRY" - don't repeat yourself (don't copy code). Helps maintainability dramatically.

2) Get an idea of patterns.

3) Joining groups like the Linux Foundation or ACM or other professional groups.

4) Reading some of the books called out in other posts in this thread.

Being professional to me means being able to write functional, readable and maintainable code. You get better at the functional part from experience. You can get pretty far I think with readable and maintainable code right much earlier in the career.

Re:Real Life Experience

[Anonymous Coward]

3) Joining groups like the Linux Foundation or ACM or other professional groups.

Learn to suck cock. It's how to get a head.

Re:Real Life Experience

[Beeftopia]

Also, focusing on writing modular and generic code. Modular meaning minimal dependencies, and generic meaning it can handle multiple situations, not just the one initially envisioned. Being able to write modular and generic code is definitely professional IMO.

Re:Real Life Experience

[wierd_w]

Nono, sucking cock is how your bosses GET HEAD, not get AHEAD.

Re:Real Life Experience

[Anonymous Coward]

You're clearly not experienced enough for the cocksucking position if you don't know there's a head on the end of the cock.

Re:Real Life Experience

[Anonymous Coward]

Is your modular code generic enough to be ready for 512-bit IPv8 today????

Re:Real Life Experience

[Anonymous Coward]

1) Things like "DRY" - don't repeat yourself (don't copy code). Helps maintainability dramatically.

You have to get the balance right. I've seen fairly advanced programmers take a ridiculously long time to accomplish a simple task because they were obsessed with code reuse - and where the results was horrible spaghetti code of tiny little three line functions - where making a small change in one place would breaks things in random places all over the code base. Sometimes two different bits of code are really doing the same thing and can share a bit of code. But, other times, you want to be able to change them independently - without having changes to one part breaking some other part.

Re:Real Life Experience

[Anonymous Coward]

Modular meaning minimal dependencies, and generic meaning it can handle multiple situations, not just the one initially envisioned.

Balance in all things. :) I've seen advanced programmers fall into the trap of taking a ridiculously long time to implement a simple bit of functionality because they were trying to anticipate all possible bits of additional functionality that might be needed in the future - and ending up with a complicated mess. Often a clean, simple, "minimal" implementation of the required functionality is better than some over-engineered pile of unnecessary complexity. Don't let the perfect become the enemy of the good.

Indentation

[whoever57]

Explain to them why they should use tabs for indentation and spaces for alignment?

Not (only) teach them

[Anonymous Coward]

1. tell them they need to learn constantly
2. introduce them to resources where they can learn from. Good books, online tutorials, youtube videos, anything relevant
3. the hardest: build self expectations in them. So they feel bad about submitting shady code.

How can he teach the next generation how to code?

[AHuxley]

Look at how the best private schools educate the best students.
Good hardware, good software, great teachers, a good environment to learn, help with computer tasks that build on many years of quality math and science education.
Private schools build on math, art, CS classes over years. The student is then full prepared for quality private higher education.
Once graduated such people are fully ready for the work force and have the connections to find work they enjoy.
Thats years of quality math and science education thats lacking from people with no formal training.
The ability to study is also lacking. The needed environment to study may also be lacking.
Try teaching a history of math and science for a while first. Get your students ready to study with a history of science, maths.
Then add a lot more useful math that will help with todays complex computer issues. Finally add in Ada or Pascal or BASIC. Such languages introduced generations to computers and allowed them to study.
Finally add todays professional computer software and build on some math skills.
Why are past generation so good with computers? They studied math.

Realworld isn't a classroom

[Anonymous Coward]

That isn't the real world. You rarely know all the variables, and rarely have a customer who knows exactly what they want before the code is written.

"Unless you start with a very clear definition"... no, you can't dictate the expertise of the customer, the perfection of the requirements, or your ability to write a bug free spec when you can't write bug free code. It doesn't make you a hacker to be flexible.

Re:Realworld isn't a classroom

[Anonymous Coward]

Agreed.

This kind of "big design up front" stuff barely worked in the early days, and trying to operate that way on any but a very small subset of project types is just lunacy these days. Even the last stalwarts of waterfall, the defense industry, is moving to adopt more agile methodologies because it's become obvious that while not perfect, it gets you a lot closer to what you want.

Re: Realworld isn't a classroom

[Anonymous Coward]

Agreed, only time BDUF works is a pure rewrite of a well-documented existing app with no change in functional requirements

Re:How can he teach the next generation how to cod

[Anonymous Coward]

If you want to code well don't bother with a university. You either can or you can't, and universities teach outdated programming concepts.

If you want to get a math, physics, or electrical engineering degree that is copacetic but stay away from computer "science".

Slashdot is for retards

[ruir]

Next article, how can I make a baby walk like an adult
How about paying proper experienced people, and put them orienting your newbies?

Re:Slashdot is for retards

[0111 1110]

More like trying to make a monkey walk like a human. Education is overrated. There are lots of dummies who get degrees, especially bachelors degrees. Find an intelligent person and they can learn whatever they need in a matter of days or weeks. Writing good code isn't really that hard. It's just machine building--an exercise in simple logic. Be smart enough to recognize other smart people to hire. Unfortunately this requires that you are intelligent yourself. Intelligence and a willingness to work hard are all you need. Then pay them fairly so they stick around. I don't think money is typically the problem though. The problem is usually that the person doing the hiring is stupid themselves and hires the worst candidates based on traditional metrics like charisma and paper certifications.

Re:Slashdot is for retards

[Anonymous Coward]

Whereas you personally always hire the best cocksucker for the blowjob. Fuck those eggheads and their book learning, am I right, bro?

Re:Slashdot is for retards

[ruir]

There is not much skill in doing a blowjob unfortunately, compared to other things. We are not talking here exactly at working at Burger King, I am afraid.
Maybe you work there for posting that.
A more apt question would be: my nephew just had the driving permit, what do I have to do for her to drive my taxi?

Re:Slashdot is for retards

[ruir]

Whilst I agree with you in the degree part, and recruiters doing the wrong questions, proof of formal training and especially experience is not so underrated.
Money is also a problem. As in the OP, they recruit unexperienced people because they do not want to pay a fair ongoing market rate.
People are also there a couple of years in that sweat shops and then move on to greener pastures.
Writing code is not really that hard, writing good code is hard. It has to be simple logic hardwired to people with good foundations and a mild/good background in IT. It used to be easier to find people that understand how computer worked, with the new wave of natives using blackboxes of ipads/androids/iphones, well forget about it.
As a former programmer, whilst I learnt a good chunk of it initially, and also some at university, I can affirm it was most beneficial to me having a 40 something old mentor once I started working in the field. He recognised my weaknesses and did his best to round me up in some fields IT and non-IT, including English.

Re:Slashdot is for retards

[JustNiz]

>> Education is overrated..... Intelligence and a willingness to work hard are all you need.

So NOT true. Sorry, but with engineering you actually do need to know what your're doing. You can hire smart monkeys and enthusiastic monkeys, but at the end of the day they're still monkeys.

>> The problem is usually that the person doing the hiring is stupid themselves and hires the worst candidates based on traditional metrics like...

"Education is overrated..... Intelligence and a willingness to work hard are all you need"

Re:Slashdot is for retards

[__aaclcg7560]

How about paying proper experienced people, and put them orienting your newbies?

That would break the HR model. Newly hired American programmers must hit the road running on Day 1 without any additional training. Therefore they need five years of experience in a technology that came out six months ago. When the employer can't find anyone, they will hire H1B programmers who don't know anything and train them in the new technology.

Re:Slashdot is for retards

[david_thornley]

Education is overrated.

Not if it helps you understand things for the rest of your career. Formal education tends to cover principles that will come in handy later, stuff that on-the-job training doesn't provide. There are, of course, crap computer science programs.

Find an intelligent person and they can learn whatever they need in a matter of days or weeks.

Nope. Some things can be learned fast, some take years. If you're asking a smart person to write in a language with concepts he or she has seen before, it will be fast. If you're asking that person to get fluent in difficult concepts, it can take years.

Writing good code isn't really that hard. It's just machine building--an exercise in simple logic.

If it's a small project, you're right. However, projects can get arbitrarily big until the people writing and maintaining them are at their limits. That's where the real benefits come in, and good code in them is much more difficult.

Re:Slashdot is for retards

[david_thornley]

I'm not an expert here, but I suspect there's a great deal of skill involved in a really good blowjob. They aren't all the same quality, although I've known guys who were happy just being able to ejaculate in a woman's mouth.

the way I did it...

[afaiktoit]

make them work on code they wrote a year ago.

Re:How can he teach the next generation how to cod

[AHuxley]

A good private university gives the person decades of connections to find a good job.
Its also showing the world a person can study outdated or any new programming concepts.

One Word

[Anonymous Coward]

Experience

Whistling in the Wind...

[Anonymous Coward]

My first response: was teach them effective collaboration strategies, but in 3 hrs?! about all you can do in 3 hrs is show them how much they don't know. 3 hours isn't enough time, imho, to do anything BUT "present stuff on best practices". That is, if you're looking for optimum use of time, 3 hours isn't really enough time to cover even the basics in detail, even in a bullet point/ machine gun/lecture format. Some have already commented that the NONTECHNICAL aspects of being a professional are important and it might help to spend 30-45 minutes defining for them what in your opinion a "professional" knows and does that a non-pro often doesn't. Whether that's work hours, salary expectations/negotiations, not showing up for work unprepared to DO work, inhospitable demeanor/behavior, work-life balance, continuing ed, dealing with difficult peers or bosses, hostile work environments, or what, is up to you. The OP doesn't specify whether this seminar is for a single company or for novices going on to various different environments with a broad range of expectations, there is rarely a one size fits all approach. Perhaps a discussion on the way A.I. is going to change what pros will be expected to do would also be helpful. (by my estimate, that's more like 3 hrs than 30 minutes right there). So, I agree with others that handing out a bibliography / reference notes is a great idea, and it would be very helpful if the books were categorized as to their major utility/focus (keywords like OOP, specifications, etc.). I think the OP has a major flaw, in that it presumes that "novice programmers" will all begin their professional careers in jobs which are uniform enough for any but very vague technical guidelines to be useful. Anyway, there already are such guidelines for what a programmer (with a BS) is expected to know.

Hazing, sleep deprivation

[Anonymous Coward]

USMC bootcamp

Practice Practice Practice

[Anonymous Coward]

I find that most young developers are very good at listening and remembering good advise. What most of them need are hours of practice.

Re:Practice Practice Practice

[Anrego]

Agree.

Also kinda said it above somewhere, but I think it's really important to set a standard early on. If you accept shitty work from them, they'll keep submitting shitty work (either because it's the path of least effort, or they just don't know it's shitty).

Do code reviews, enforce them, require their work to meet a certain level of quality (and kick it back when it doesn't), and most people people will rise to that standard. If you enforce that all public methods must have good comments, and consistently kick back code with no comments or shitty/ineffective comments, people will start habitually doing it right because they know they can't get away with doing it wrong.

Comments and Documentation

[Anonymous Coward]

Teach them to better comment and document their work. Code should be written for humans just as much as it's written for machines.

Re:Comments and Documentation

[Anonymous Coward]

I never write comments. The machine can understand my code, so if you can't understand it, you're stupider than the machine and not qualified to maintain the code.

Flyover country

[hackwrench]

He could reside in "flyover country". https://www.wired.com/2017/03/...

Re:Flyover country

[Anonymous Coward]

I grew up in lincoln. 20+ years ago there were 3-5 places to get programming jobs. Not much has changed.

The real story is no one wants to train in these areas. They have some tech stack some dude foisted upon them 5-10 years ago. They are stuck with it. They then only want to hire people with those exact skills. Then pay 30% under rate. Then bitch they can not find anyone. I moved away and got a 50% pay increase at the same cost of living. Mostly they are paying under rate. I saw one a few weeks ago that wanted to pay 60k in the denver area for 10+ years c++ exp and a few different frameworks. In that area something like that should be 95-120k.

Raises the question

[Tinsoldier314]

I think you meant begs the question. Saying it, "raises the question" is pretty dated phrasing.

Re:Raises the question

[Anonymous Coward]

"Begs the question" actually means something entirely different. "Raises the question" is what's meant, so it's better phrasing than the (common) misuse of the more popular phrase.

Key point is to make them unlearn how they program

[Anonymous Coward]

Programmers come from schooling or self-thought with very bad habits because their teachers are clueless.

Point 1: they are making a business asset not hacking together something for themselves or a class assignment.

Point 2: they need to follow documented company coding standards. originality here is not helpful or productive.

Point 3: their code will live beyond them and be subjected to multiple modifications over its life. It must be written to be modified with that in mind.

Point 4: Towards 3, it must be written to be read. Another programmer should be able to read and understand its function quickly. So the code should be written for readability and to be understood rather than to show off. Comments should all any the question why? not what? Variable names should be clear and helpful, follow defined coding standards, and be correctly typed not just within the language itslef but the variable's use. Ordinal and cardinal numbers are different things.

Point 5: Explain that textbook examples were written by those who teach not those that do. Give them examples of the best code produced.

Point 6: Make them critical of their own code and push the idea of craftsmanship. A spelling error or typo in a comment is an indication that the code has not been read after being written so there probably is a bug there somewhere.

Point 7: The Psychology of Computer Programming is a classic text. Producing good code is not an individual activity. All code should be subject to a peer structured walkthrough. Every programmer needs to give their best not just as a coder but also as a reviewer of others code.

Read TAOCP vols 1-4

[Anonymous Coward]

THEN you can start coding here, kid.

Re:Read TAOCP vols 1-4

[Anonymous Coward]

Knuth is an elderly old man who has nothing to teach young people who have no time to read the obsolete opinions of dinosaurs.

Re:Read TAOCP vols 1-4

[Anonymous Coward]

You can't handle the Knuth!

Lol

[Anonymous Coward]

How do you make experienced programmers more professional?

Re:Lol

[Anonymous Coward]

Make them younger.

What he's really aasking...

[Excelcia]

What he's really asking is "How do I make a millenial not".

Once you find the answer to that, my friend, please come back and tell the rest of us.

Re:Key point is to make them unlearn how they prog

[0111 1110]

Why would anyone want to be a professional programmer if that is what it is all about? It doesn't sound particularly fun or challenging. It sounds like more like something out of 1984 or Brazil. I like to code because it is fun to build a machine--a sort of intricate wind up toy--that you actually get to run eventually. What you describe sounds more like being a slave. I guess I can see why they have to pay so much or go to India. That's not how I would want to live my life. Do these 'professional' programmers have high rates of suicide?

Two Links

[darkain]

First, read this: http://kotaku.com/5975610/the-...
That is an analysis of the coding style used in the Doom 3 source code

Next, read this: ftp://ftp.idsoftware.com/idstu...
It is linked within the first article, but it is important enough to directly reference. It is id Software's official programming guidelines. Seriously, just having clean, clear, consistent guidelines for source code makes a world of difference in quality.

The very first thing to teach young'ns is this:
"Programs must be written for people to read, and only incidentally for machines to execute."

No dress codes, eh?

[Anonymous Coward]

Perhaps we should do away with pointless dress codes, especially the ones with dependencies on 14th century fashion.

Found the slob. Or crazy feminist. Or.... both.

This is a continuous process, not one-time trainin

[MobyDisk]

Accept that this isn't a single tutorial, but a continuous process of teaching and learning. And failing! Here's some tips I recommend:
1. Don't dump every best practice you can on them at once.
2. As you see individuals demonstrate these skills, have them present it to the group.
3. Use code reviews so that they are motivated to catch each others mistakes during reviews, then are motivated to not make those mistakes themselves.
4. Have senior members of the team demonstrate these practices and participate in reviews and mentorship.
5. Assign them work that will improve their best practices. Maybe cleaning up an existing module, documenting a particularly difficult area, or reading a chapter in a book and finding an example in your code base where it could have been applied.
6. Accept commentary and debate. There are always exceptions.

Code reviews

[Anonymous Coward]

Most companies have some kind of code review process. This helps new engineers sharpen their skills through feedback, and familiarity of code not written by themselves.

Easy

[Anonymous Coward]

Take 100 novice programmers, have them work for 10 years. If there are any left that you didn't have to fire, there's your professional.

Zero Bugs and Program Faster, 10 minutes in bathro

[raymorris]

> For programming skill, I'm going to suggest Zero Bugs and Program Faster

I second that, good book. Specifically it's a collection of good ideas, each of which takes about ten minutes to read. Zero Bugs and Program Faster would be an excellent choice if you want to spend just a few minutes each day, to have continuous slow improvement. It was my bathroom reading for a while and it was perfect for that.

(If you assembled the top 50 best forum posts related to creating robust software, you'd end up with something like this book - about 50 seperate good ideas that are only loosely related.)

Another way to use that book would be to read the same short section each day for a week, so by the end of the week the idea has found a permanent home in your brain.

rigor

[gravewax]

Coding standards documentation, Peer review of their code and gated checkins. They either learn to be more professional or they quickly are identified as someone you don't want and you do that as an educational experience, it is ok to make a mistakes as long as you aren't repeatedly making the same ones.

Non-professional programmers...

[__aaclcg7560]

How do you become a more professional programmer when your full time job isn't programming?

I was a video game tester for six years, went back to school to get an A.S. degree in computer programming, and got into IT support because I enjoy the work. I program at home (Python and web development) and occasionally write PowerShell scripts at work, but the only time I deal with other programmers is when I'm cleaning up their messes over the network at work.

BTW, Microsoft SharePoint IS NOT a proper bug tracking tool.

10 helpful ideas for n00bs

[Anonymous Coward]

1. Writing code means you have already failed
2. The more code you write the more you fail
3. Failing is bad, don't fail.
4. You don't need to fail to learn that failing is not good.
5. The non-programmer guy in the backroom who is a domain expert in whatever your software is supposed to do is more qualified to do your job than you as a "programmer" will ever be.
6. Progress is the process of circular "rediscovery" of concepts well understood by others long before you were born.
7. Software industry is driven by viral propagation of temporary fads completely disconnected from merit.
8. The better your tools the better your chances of being fooled by them.
9. DSLs are always better than general purpose languages.
10. Never work more than a 40 hour week for any reason.

Professional developer turned trainer

[LostMyBeaver]

I've been a developer since I was a child. I became a software engineer after education. I have been a senior developer on at least 3 projects that have impacted a billion or more people for 5-10 years and have a list of "inventions" to my name that is quite long.

I am not properly educated. I couldn't afford to attend the university in America, so instead, I latched on to the head of science and engineering at a major university and traded work for books etc... but I received no paper. I was forced to know every book verbatim at all times for years because in order to work in generally Ph.D. level positions and be taken seriously, I had to be a walking reference at all times. It was a bumpy road, and I got my scars, but I made it.

I become a structure zealot. I became absolutely obsessed with Big-O, data structures in general, design patterns, etc... I rarely if ever wrote a piece of code without obsessing over its design extensively before doing it. I learned that all the best programming started on the backs of napkins at coffee shops. A local coffee shop even let me and a colleague use white board markers on their windows for an hour or two each day because we were costing them a fortune in napkins they said. We often had an audience, less professional developers wanting to learn how to plan and employ complex things.

Together my colleague and I reinvented methods of programming such as methods of decoding images using a push pipeline rather than simply a FIFO by designing state machines similar to VHDL coding that would decode and display pixel by pixel of an image (jpeg, png, gif) as soon as the data was available. We designed new methods of compiling lex and yacc grammars that would dispense of tables and handle contexts while also processing data as it arrives based on state machines and make corrections if new data changes the meaning of older data. We wrote memory allocators, just-in-time compilers (back before they were properly named).

None of these tasks could have been accomplished without
1) Education
2) Reading to further education
3) A thorough understanding of computers (we were both demo coders when that meant something)
4) Math
5) Patience
6) Respect for each other instead of competition.

Now, I've gotten old and I decided I liked money a lot, so I left my job as a programmer after nearly 20 years and moved onto being an network instructor. First of all, networking people are all very similar to informally trained programmers. They're typically more talk and less real knowledge. They spout off things they don't fully understand and they often find them to be mysterious and amazing. They learn a new acronym like HSM and even learn it means Hierarchical State Machine and before you know it, your code is littered with chaotic amounts of junk because every problem they try to solve, they employ their new toy to solve. Sadly, it's not magical and they make coding changes that will permanently impede your ability to work professionally since training new programmers on the project will now take 3 times as long.

Let's start with a few bullet points :

1) New languages can bring new methods, but new languages come and go
PERL, PHP, Ruby, Python, what's next?
Due to children making decisions all the time, there are companies with millions of likes of bad PERL, PHP, Ruby and Python code out there. Each time there's a new "hot language" we end up rewriting absolutely everything over and over and get it wrong over and over. Those languages are great for some reasons, but while I use Python once in a while, I generally limit how much I use it since I expect support to slowly taper off within 3-5 years. I may be wrong, but it's a "language of the week" and I don't believe in investing in languages of the week.

2) Communication is the absolutely most important thing
Algorithms, Desi

Re:Professional developer turned trainer

[OrangeTide]

Right. One thing people don't realize that in some careers you can't just stop learning once you have that degree. Engineers, scientists, doctors, software developers and others have to continue reading and experimenting to stay current. Most successful computer programmers I have seen are obsessive readers. And I don't mean they read industry magazines, they're reading papers and thick tomes on a regular basis. I believe this is why informally trained programmers are able to compete with their degree holding peers.

I've had to clean up projects done by bad C programmers. There are bad programmers in every language, and they usually form from a combination of inexperience, arrogant and apathy. The language of the week fad is annoying to me, but in retrospect I am glad that people are trying out more than one language rather than everyone turning into a Java drone.

Meeting requirements 40 years in the future

[raymorris]

As you said, the common way of getting software requirements doesn't work too well, and certainly doesn't work *reliably*.

I have a book from the 1970s that describes many of the programs I use every week. They still serve the requirements 40 years later. I'll come back to that set of programs, and how they predicted requirements 40 years down the road, at the end of my post.

Before getting to the 40 year old programs that are still used daily around the world, this topic reminds me of one of the best software design tips that I've been taught. In retrospect it seems obvious, but many programmers haven't thought to do it, and most don't insist on doing it.

90% of the time, you're writing software to better do something that's currently being done some other way. Perhaps you're replacing legacy software, perhaps it's currently being done "manually", people entering data one item at a time. Perhaps you're replacing a paper-based system. Most of the time, you're replacing *some* method of doing the same task.

It logically follows, then, that to fully understand the process, it's requirements and idiosyncrasies, you can watch the people actually doing it. Even better, have them show you how they do it, then try to do the job yourself while they watch and correct you or point out things to be careful of. Take notes during this. Most likely, the way they are using the old system is NOT how it was designed to be used, because the designers of the old system weren't clear on the requirements. But users find a way of meeting their requirements. Watching how they do that shows you what they actually need to get their job done.

Already just by watching them do the task you'll understand the requirements far better than you would by having a meeting with their boss's boss (the common, bad, way to get requirements). After watching them do the task, next ask them two questions:

What about the current process or tools is frustrating for you, or slows you down?

Pretending *anything* is possible, what would your impossible wishes be for this?

The second question often elicits ideas that allow the programmer to say "I can do that, that's easy". Then you begin to glow with heavenly lights because they thought their wish couldn't possibly be granted. Truly, I've done EASY programming tasks that have garnered me a reputation for being able to do the impossible, simply by asking the users what impossible features they wish I could provide. Their conception of what's easy and what's impossible is totally unrelated to what a good programmer can actually do. (You've probably noticed users often think it should be easy for us to do something that's actually nearly impossible. The flip side of that same ignorance is that they think we can't do stuff that we can actually do pretty easily.)

I didn't come up with any of this myself, these aren't my genius ideas and I wouldn't expect anyone else to think of these things. These are things I've been taught along the way, and I wouldn't expect another programmer to think of them, until they are also taught these ideas.

One more thought, or set of thoughts about foreseeing requirements. I was also taught that you can, fairly easily, plan for and program for future requirements without knowing what those future requirements will be. There are two major ways of doing that, both closely related. One is to avoid hardcoding unnecessary limitations. As an example, configuration for my software never has the user provide a configuration value. Instead, each configuration item is a LIST. If my software can send email notifications, it isn't configured with an email address to send to, it's configured with a list of email addreses. If it can read from a data file, it can read from a list of data files, etc. In the code, the added flexibility requires just this additional code:
foreach {
}
That's it. Just "foreach" whenever a configured value is used makes the whole system far more flexible. This is an example of not ar

Re:Meeting requirements 40 years in the future

[Gaby de Wilde]

The foreach reminds me of this funny I wrote a while back http://arguments-accepted.go-h... It sort of crudely extends the idea with: Why try to predict usage if it can accept anything?

Re:Meeting requirements 40 years in the future

[Thelasko]

The method you describe is a popular Japanese management practice called Gemba. I've done it before, and it can be extremely valuable if you can convince the customer to cooperate.

Just remember, customers don't always know what they want.

What are you thinking?

[JustNiz]

Send them on a Computer Science degree course.
Its clueless to think that programming to a professional level is something you can learn in a few hours. ... or maybe you're one of those people that would be happy if your surgeon turns out to actually be a plumber that just felt like having a go at surgery after watching a youtube video.

Pair Programming

[s1d3track3D]

Say what you will about it, I've found pair programming a strong Sr. level developer with a junior one of the fastest way to improve the junior's skills.

Re:Pair Programming

[JustNiz]

...and cause your Sr Developer to wanna bang his head on the desk all day..and ultimately quit.

Re:Professional programmer?

[UnknownSoldier]

> First of all, I have an issue in using the concept of "professional programmer"

Professional programmer, noun, someone who has made programming their primary CAREER and has a recognized formal education.

In contradistinction to Amateur, noun, someone who has no formal training, and may, or may not do the job better. Programming is NOT their primary career.

/sarcasm Maybe you should try cracking open a dictionary sometime -- you might learn something.

Re:Zero Bugs and Program Faster, 10 minutes in bat

[UnknownSoldier]

>> For programming skill, I'm going to suggest Zero Bugs and Program Faster
> I second that, good book.

I'll third that book. Great book !

You Aren't Professional

[Anonymous Coward]

A) You don't know what to teach, so you should be teaching.
B) You're trying to build coursework by asking /. to achieve your retirement objectives, further proving you shouldn't be speaking on programming.

Right tool for the job

[Anonymous Coward]

A comment my father used to make that took me a long time to fully understand was "Sure, bang it in with a wrench." That is, a true craftsman doesn't use a wrench as a hammer: they use the right tool for the job.

Novice programmers typically choose the wrong "tool" (language, library, design, algorithm, etc) because they're not even aware of the right tool - writing a complex graphical interface program entirely in Perl because that's all they know.

Intermediate programmers typically choose the wrong tool because they want to grow beyond their current job - writing all the company's shell scripts in assembly because they want to learn assembly.

Advanced programmers typically choose the wrong tool because they want to show off how smart they are - implementing core functionality in a language they designed themselves so they can brag about it to their friends.

Ultimately, in a professional settings you want simple solutions to hard problems. Code that's easy to understand, easy to debug, easy to modify. Of course, too often you get the opposite: complicated solutions to easy problems. :)

For the novice programmers, the path to becoming a better programmer is simple but time consuming: learn about all the different tools that are available and when, and when not, to use them. Having your own hobby project on the side is very good for this.

For intermediate programmers, having your own hobby projects is also good - better to write your own little open source device driver in assemby than the company shell scripts if you want to learn assembly.

But for advanced programmers, the path to becoming a better programmer is more difficult. Essentially, you have to let go of trying to prove to the world just how smart you are. John Cleese got into psychology after Monty Python and wrote a very nice book "Life and How to Survive It" about how to be a "gold medalist of mental health". He's also got an excellent YouTube video on creativity, for example

Inspire them

[Kormoran]

I'm pretty sure you won't teach them a lot in three hours. Maybe some very basic concept, something they could learn on their own (and faster) in a CS introductory book. I think you could achieve more trying to inspire them. Programming is great, programming is the making of worlds by your own hands, when you code you are a small-scale god. Next, tell them about coding horror stories, team stories, pitfalls, let them think that CS learning is needed and worthy. Show them there are giants whose shoulders they can climb and reach farther than they could. The movie "Invictus" has a scene when Mandela talks to the team leader:

- Nelson Mandela: How do you inspire your team to do their best?

- Francois Pienaar: By example. I've always thought to lead by example, sir.

- Nelson Mandela: Well, that is right. That is exactly right. But how do we get them to be better then they think they CAN be? That is very difficult, I find. Inspiration, perhaps. How do we inspire ourselves to greatness when nothing less will do? How do we inspire everyone around us? I sometimes think it is by using the work of others.

Its bit the young ones you have to worry about

[MichaelSmith]

Its the old programmers who haven't learned a thing in 20 years, and who will never change.

Re:Its bit the young ones you have to worry about

[MichaelSmith]

^not

Re:How to make them more professional

[sycodon]

NO.

Tell them to go into Web Development.

Then be hired by Slashdot. Then create with a Slashdot site that doesn't jump up and down like a God Damned Fucking spastic French Poodle when you are trying to read/post/moderate the fucking articles.

Based on how Slashdot pages are behaving, they don't even have trained monkeys working for them, but rather drooling, hydrocephalic, brain damaged shit heads that delight in ruining any web page they can smear their feces on.

HOLY FUCKING SHIT Slashdot!!!!
WHAT THEY FUCK????

Well, perhaps allow them to grow

[Anonymous Coward]

There are several pre-conceived notions about programmers.

1) You are born with some sort of aspergers syndrom that makes you super human with code

2) Your inability to socialize makes you super human with code

Both of these are false.

A programmer grows like a plant with layer upon small layer of knowledge and experience. It takes a hell of an investment in time and a very particular personality which is hungry for the knowledge and constantly reaches out for more.

There is no secret sauce, there is no steroid you can give a person to make them a faster stronger programmer.

Team code reviews

[Anonymous Coward]

Team code reviews.

Make certain that everyone does it. Do not let anyone know in advance, just review all the code that was checked in last week. Don't let the actual programmer explain it. The coder sits on the sidelines during reviews. Teams of 4 people. Turns out that 3 reviewers is the optimal for uncovering mistakes, assuming they actually LOOK at the code and critique it.

I worked in a place that did formal code reviews. Took about 8 months to turn someone who didn't know the language into an expert. Yes, there are gaps in knowledge. There are always gaps. Nothing can fix those except time and experience.

But reviewing code - both great code and not-so-great code - is good for everyone.

Re:Team code reviews

[Anonymous Coward]

I've removed team leads for wasting engineering time with this kind of garbage. (well, I removed them after they refused to adapt to my way of thinking)

It's one thing to establish a methodical process for reviewing every check-in. And ideally with a goal to limit the amount of time you spend on the process.

But to bring 4 engineers in a room for an hour to aimlessly slog through commits is a huge waste of company resources.

Just run static analysis, fix the reports, use continuous integration and peer review every commit with only 2 people. The data you generate from the reviews, bug reports and CI testing can be tracked to find the individuals who need work on both the coding size and the review efficiency side.

Pair programming or peer review

[Anonymous Coward]

You can't teach good programming in a seminar, though you can teach some basics (Goto's considered harmful, think objects, etc.).

You show how it's done, get the apprentice to do some, then criticize their work.

Mentoring in the Workplace

[Anonymous Coward]

I interview and train all new hires to our department. A new hire consumes about 20% of my time per week for the first two months and 10% the next four months thereafter. When we hire its a commitment and intend to see our new coworker successful. Some tips:

1) Assign recent but already solved problems. See how they solve it. Make corrections along the way, and on rare occasion, they'll think of something the team didn't.
2) Have them create a small internal tool that will benefit the team. It should not be mission critical but it should be used daily and they WILL be responsible for it.
3) Give them current production code and ask "what would you improve / change here?". Take out the author of the code name. Point out where their logic is sound, and, where its not.
4) Explain project management, politics and business issues as they come up in those first six months.
5) Go out and have some drinks with the person after hours on a handful of occasions for items that cannot be discussed in the office.


For those wondering if this is too much hand-holding, no its not. This is an investment we fully intend to make the most out of. The personal time spent ensures the new hire doesn't walk out the door in the first two years, and, fewer mistakes are made once they are assigned real work. End of the day - we do get a return on the investment.

Recommend some books.

[Ihlosi]

Stuff like "Code Complete", that don't explain how to write code, but how to write code so it's readable, understandable, debuggable and maintainable.

Re:How to make them more professional

[Anonymous Coward]

Agree. The jank is insane on these pages.

Re: Key point is to make them unlearn how they pro

[Anonymous Coward]

The problem solving is the challenge and why does it have to be fun? What is fun anyway? Would you really want a surgeon or policeman to look for their job to be fun? Craftsmen get satisfaction from building something that works elegantly. Having self-pleasuring "fun" and "being creative and artistic" is what generates the crap software the rest of the world needs to deal with.

Re: Professional programmer?

[Anonymous Coward]

Whiny bitch comments like this are unprofessional. I'm guessing you're a novice programmer and amateur troll.

We learn how to write great software by doing it.

[svetzal]

Nothing teaches people more about writing code than actually writing code. Given novice developers' hesitance to throw away code they've written that works, iteratively walk them through some "real life" crazy requirements changes, and then talk about the monsters they wrote and how they evolved. I like 30m iterations. Highlight some of your favourite practices as incidentals (ie. hey, that's a nifty comment but now it's a lie, what if you'd commented why instead of what?, or hey, that function called "do the thing" doesn't actually "do the thing" does it? How'd that happen?) This gives you (and probably a couple extra) facilitators time to run around the room and see what they put together. It can also be tricky to build up the room as a "safe space" where folks have the courage to share their blunders. But if you pull it off, it's magic.

case examples

[sugar and acid]

Demonstrate the value of good practice. The difference between inexperience and experience is the experienced have made the mistakes and seen the consequences of other mistakes. The point of all those software approaches is that they improve end software quality,and medium to longer term improve maintainability and extensiblility of the code. (If they don't achieve any of those, you probably should get rid of the process).

The real problem with inexperienced programmers is they haven't seen the result on a large code base and project of not following good practice. So they can't see the value yet.

Very simply, try and demonstrate the value. Eg two pieces of code, one with poor structure and commenting and one written to a good standard. Have them change some functionality in each and validate the change. The poorly written bit of code will be a pig, the code that is to standard easy and the automated testing will give them a nice little validation of the result. Drive home why the better written code was easier to work with.

It will also let you weed out the really destructive programmers early, the ones that never learn the value of good coding practice.

examples from your career

[Anonymous Coward]

Here's a suggestion for a framework for a talk I think people might find interesting. Focus on process and use two examples: one success and one failure. Start with the problem you were trying to solve and show how the code evolved, explaining both the technical and organizational issues that led to the success/failure. Make it visual (show the code) and temporal (go through the timeline of development). Throw in plenty of light jabs at management to add levity. Cover all your pet peaves but don't get stuck on one for too long. What the hell do I know, you're the lecturer.

seriously

[Anonymous Coward]

no facebook, unless you are zuch bitch and a complete retard
no girlfriend, unless she is also a programmer and aid you reading the fucking linux kernel
no games, unless you are an aspiring artificial intelligence analyst
no drugs, unless it's mariujuana. seriously hemp is okay compared with coke
no jokes, because you must wath monty pyhon to know the jargoons, not behave like a clown

Make sure they add comments and build a debug

[TheOuterLinux]

Make sure the programmers add comments to each section that does different things, especially when collaborating. Nothing worse than editing a script file and then another guy changes a bunch of variables with no explanation. Also, have a debugger handy as soon as possible. Even if you're using something like Bash, Python, Java, make sure to have it echo or print out variables as it runs. You can use a special comment like "#DebugEcho" beside them to find and clear them out latter. Also, GitHub is the king of collaboration. I think private projects cost money, but are free to students. I got an account, but it's been a while since I signed up. I did it originally for the free Unreal Engine. And for the love of god Githubbers, please include a configure file for source compiling. I'm sick of getting M4 errors trying to make one. I guess another point to touch on is to test your code on as many platforms as possible. Not all Linux behaves the same if that's your target. If it's not, don't talk me. Hahaha....

Doxygen

[Anonymous Coward]

Install Doxygen. Let them see how crappy their code looks and show them how to fix it.

We worship at the altar of youth here.

[w3woody]

The problem is that our industry, unlike every other single industry except acting and modeling (and note neither are known for "intelligence") worship at the altar of youth. I don't know the number of people I've encountered who tell me that by being older, my experience is worthless since all the stuff I've learned has become obsolete.

This, despite the fact that the dominant operating systems used in most systems is based on an operating system that is nearly 50 years old, the "new" features being added to many "modern" languages are really concepts from languages that are between 50 and 60 years old or older, and most of the concepts we bandy about as cutting edge were developed from 20 to 50 years ago.

It also doesn't help that the youth whose accomplishments we worship usually get concepts wrong. I don't know the number of times I've seen someone claim code was refactored along some new-fangled "improvement" over an "outdated" design pattern who wrote objects that bare no resemblance to the pattern they claim to be following. (In the case above, the classes they used included "modules" and "models", neither which are part of the VIPER backronym.) And when I indicate that the "massive view controller" problem often represents a misunderstanding as to what constitutes a model and what constitutes a view, I'm told that I have no idea what I'm talking about--despite having more experience than the critic has been alive, and despite graduating from Caltech--meaning I'm probably not a complete idiot.)

Our industry is rife with arrogance, and often the arrogance of the young and inexperienced. Our industry seems to value "cowboys" despite doing everything it can (with the management technique "flavor of the month") to stop "cowboys." Our industry is agist, sexist, one where the blind leads the blind, and seminal works attempting to understand the problem of development go ignored.

How many of you have seen code which seems developed using "design pattern" roulette? Don't know what you're doing? Spin the wheel!

Ours is also one of the fewest industries based on scientific research which blatantly ignores the research, unless it is popularized in shallow books which rarely explore anything in depth. We have a constant churn of technologies which are often pointless, introducing new languages using extreme hype which is often unwarranted as those languages seldom expand beyond a basic domain representing a subset of LISP. I can't think of a single developer I've met professionally who belong to the ACM or to IEEE, and when they run into an interesting problem tend to search Github or Stack Overflow, even when it is a basic algorithm problem. (I've met programmers with years of experience who couldn't write code to maintain a linked list.)

So what do we do?

Beats the hell out of me. You cannot teach if your audience revels in its ignorance and doesn't

Re:We worship at the altar of youth here.

[Tangential]

I agree with your comments but I would also add that I think we have a tendency today to assume that all a programmer needs to know is the language and the tools. I've found that it is very rare for a programmer to do a truly acceptable and successful job if they don't thoroughly understand the problem that they are solving, The belief that we can document requirements well enough to send them to programmers who have zero understanding of the problem or its domain is leading to a lot of bad code, late, incomplete solutions and unhappy users. We don't hand residential framing carpenters the plans to a sailing vessel and assume that because they have the plans they are now shipwrights and can do a great job building it; we shouldn't do that with developers either.

Re:We worship at the altar of youth here.

[ackkamoto]

This needs to be shared to every undergrad computer science and all over silicon valley.

Re:We worship at the altar of youth here.

[wallstprog]

It's interesting -- I'm watching spring training games on TV, and what you see there is a whole bunch of old guys (coaches and managers) telling a whole bunch of young guys how to play the game. (My personal favorite is Terry Collins, who is 67, and who is constantly in teaching mode).

This is considered normal in baseball -- it's taken for granted that the old guys know a whole lot more about how to play the game than the youngsters, and the youngsters have no problem with that. (And the smart ones go out of their way to soak up as much of that knowledge as they can).

Re:We worship at the altar of youth here.

[Bright Apollo]

I'm with you on almost every single point -- I'm a late 40s dev myself -- except this one part: " I can't think of a single developer I've met professionally who belong to the ACM or to IEEE, and when they run into an interesting problem tend to search Github or Stack Overflow, even when it is a basic algorithm problem. (I've met programmers with years of experience who couldn't write code to maintain a linked list.)"

1) I left ACM when it became apparent that the benefits of CACM readings didn't outweigh the harm they do by locking up research behind so many paywalls and special publications. It's a reasoned, principled decision that has nothing to do with a lack of interest in staying current. So, ACM or IEEE membership isn't a pure indicator of attention to craft that I perceive in your statement.

2) I can't write a linked list from memory, first try. I can't write qsort in C anymore without looking it up, and don't ask me to do a mergesort in Javascript. I can't keep all of that in my head, for the very simple fact that I don't need to. Lots of programmers are accomplished, and look shit up all the time https://theoutline.com/post/1166/programmers-are-confessing-their-coding-sins-to-protest-a-broken-job-interview-process

--#

Re:We worship at the altar of youth here.

[Anonymous Coward]

With 35+ years experience, I'm frustrated that devs fresh out of college lack rudimentary discipline in their coding, and lack of foundation knowledge. During my time working for a major university, I audited a data encryption class (600 level). These people already had computer science degrees, and literally only 2 students knew what an XOR was. And now they are pumping out "developers" from 90-180 day retraining programs that companies are picking up at reduced wages that I have to train on the job. Our field of endeavor is being reduced from a profession to the equivalent of fast food workers pumping out substandard products for cheapest price at maximum volume, and the hell with quality. We'll just fix it post release...

Re:We worship at the altar of youth here.

[Anonymous Coward]

"agile", otherwise known as the current iteration of the rapid application development religion (agile wasn't the first folks), it is not benefiting anyone. Rapid development methodologies have been producing crappy, undocumented code for 30 years now. If I had any advice for young developers today it would be learn design patterns and their proper application, learn to use bit operators, go back and take advanced mathematics until you can write a mathematical algorithm to represent a problem, an "if" requires an "else" regardless of your confidence that everything will be set upon entry, learn how to convert your condition tests to positive logic, and stop throwing in new technologies for the technologies sake or resume padding. A 5 page website doesn't necessarily require wordpress, nginx, grunt, node and every service offered by aws. IOW learn to program, and you can do so in ANY language because learning the differences in syntax is easy.

Re:We worship at the altar of youth here.

[tatman]

This is spot on. And I suspect the blame goes around to a lot of different areas:

First of all, business only cares about the $ being spent right now. Because there is no ability to track the cost to fix an error found in the future to decisions made today there is no incentive to think about long term costs other than immediate labor costs.

And there's this crazy idea that more programmers means the work will get done sooner. So if you can get 2 or 3 junior programmers working for the cost of 1 veteran, the spreadsheet says the work will get done sooner (I am not advocating it does).

Then there's our colleges. They teach a language, and all its logic constructs, but they do not teach practical application of those principles. And they do definitely do not work with real life examples (I remember someone taking a programming class taught by an accountant and given code that was not even written in correct syntax that would compile).

It's very frustrating.

Re:We worship at the altar of youth here.

[Anonymous Coward]

So you are not worshiping at the altar of RAD, but you're praying to the gods of Design Patterns. I've got some bad news for you: they are both false.

Re:We worship at the altar of youth here.

[w3woody]

I left ACM when it became apparent that the benefits of CACM readings didn't outweigh the harm they do by locking up research behind so many paywalls and special publications.

Two thoughts. First, I'm old enough to remember a time when all information required either a subscription, for you to buy the books or subscribe to the journals, or were a student or a member of an alumni association which granted you access to the libraries where you would physically go to read the latest and greatest. So to me, the idea that I should pay for a subscription to keep abreast of the latest stuff isn't really a foreign idea. That said, the quality of the information now available for free on the Internet is good enough one really doesn't need a subscription.

Second, however, I know quite a few people who don't even know that these organizations exist, or what the benefits are. And while that doesn't bother me, my real point is that I've met a number of developers who, when I explain these organizations, think they're completely worthless without investigating it themselves. Meaning they are not just ignorant, but have no desire to learn, and consider it completely worthless.

Re:We worship at the altar of youth here.

[Anonymous Coward]

What's with the "advanced mathematics" advice? You need exactly zero knowledge of advanced mathematics to be able to write a good algorithm.

Re:We worship at the altar of youth here.

[Anonymous Coward]

Agree with a lot of what you have written. However, wanted to pick your brain on "who believe all code is "self-documenting."" though. Here I am assuming that you expect documentation to be maintained outside of the source code.

Here is my take on it...

If it is a public API (generally defined as "will be consumed by a client for whom the implementation is a black-box"), then YES, clear documentation on API and its usage is absolutely warranted.

If it is NOT a public API, I would only use line/block comments inside of source code to make brief/extensive notes to describe implementation. In my experience, any attempt to maintain separate documentation is not useful because (i) notes are relevant only to developers and we prefer it right next to the actual implementation and (ii) such notes are much easier to keep up-to-date in source code right next to the implementation - this way, a single person, the developer, is responsible for keeping implementation and notes/documentation in sync (no technical writer required).

Your thoughts?

Re:We worship at the altar of youth here.

[Anonymous Coward]

Here's a real world example:

Using the image of a tire, detect a below optimal pressure state. Can be done with a single equation IF you have the right tools in your belt. Writing a "good algorithm" isn't the same thing as replacing 90% of the code and gaining a 1000 fold performance increase simply by using an equation.

When I went to school, the only difference between a computer science and applied mathematics degree was a single course. There's a reason FORTRAN is 60 years old and still in use, and was the first programming language written.

Re:We worship at the altar of youth here.

[Anonymous Coward]

My thoughts are that implementation comments are necessary and probably appropriate to put in the block header. However, it is also my experience that the person who writes the code and the person who must later modify or maintain the code are rarely the same person. Sometimes we come up with a clever or shortcut solution to a problem because when we write the code we know part of the work is being performed by another function that was called earlier in the process. Those inter-dependencies, or the clever solution I came up with may be unknown to the developer that comes after me, who then makes a seemingly simple change only to have the entire house of cards come crashing down. So function level documentation and process level documentation are different animals the latter of which is NOT satisfied by comments within the function.

A good technical writer works hand in hand with the customer, project manager and the developers to document processes and their implementation in functions/api and makes the job of the person who takes over for you 5 years from now MUCH easier, makes the developers job easier by providing well defined requirements, makes the project managers job easier by having the right information to manage customer expectations, and makes the customers life easier because the software they defined is the software they get and can better manage the cost because they can see when and where a change request impacts requirements.

Re:We worship at the altar of youth here.

[Anonymous Coward]

Sex is another area where it seems as if complete rookies ( aka virgins) are valued more than folks with experience. One possible reason older couples have sex less frequently is because they're probably really good at it (unless experience really doesn't count).

Re:We worship at the altar of youth here.

[Anonymous Coward]

I learned a lot about sex (not the clinical "health class" stuff) from reading Penthouse Forum, no joke. Terminology if not technique.

Book learning only takes you so far. There's no substitute for experience. Learn by doing! :)

Re:We worship at the altar of youth here.

[w3woody]

Comments, like many things in software development, are really a matter of personal style--though they do serve the purpose of making it clear what your code is supposed to do, so the guy who maintains it later can have an understanding of what is supposed to be going on.

So I tend to lean towards a block comment per non-trivial (10 lines or more) function or method--though sometimes the block comment may be at most a sentence. (I don't think the name of the method or function is sufficient commentary enough simply because cultural differences may make a non-native English speaker unable to translate your personal naming conventions.) I also tend to lean towards describing how complex sections of code work if they appear "non-trivial" to me--meaning if I'm doing more than just calling a handful of other methods in sequence or looping through a bunch of stuff which was clearly noted elsewhere.

I also tend to write code like I write English: a single whitespace used to separate two blocks of code, and moving functionality that is associated into their own blocks (where shifting functionality does not impair the app) is preferable. I also tend to block chunks of methods in a class which are related with each other; the Apple C/C++/Objective C compiler provides the #pragma mark directive to help provide a one line comment to help identify the functionality of those groups of methods.

If I'm doing something really non-trivial--for example, implementing a non-trivial algorithm out of a book (such as a triangulation algorithm for converting a polygon into a triangle) I will start the block comment with a proper bibliographic citation to the book, the edition of the book, the chapter, page number, and (if the book provides) algorithm number of the algorithm I've implemented. (I won't copy the book; the reference should be sufficient.) If the algorithm is available on a web page I'll cite the web page. And at times when I've developed my own algorithm, I will often write it up in a blog post detailing the algorithm and refer to that in my code. (When done as a contractor I'll look for their internal wiki or, if necessary, check in a PDF to the source kit.)

Back when I started doing this a long time ago, technical writers were sometimes used to help document APIs and the project requirements of the project. The reason for having a separate technical writer was because by having a person embedded in a project who is not intimately familiar with the project, they know the right questions to ask to help document the project to an outsider, being an outsider themselves. Developers cannot do this. Developers, being too close to the code they work on, will often run the code down the "happy path" not thinking of the edge cases to run, and they won't describe things they think is obvious (like "of course you must call API endpoint 416 before calling API endpoint 397; the output of 416 must be transformed via the function blazsplat before calling 397, and how do you get the input to blazsplat?). A really good technical writer could also help to distill the "gestalt" of the thing, helping to find the "why" which then makes code or project specifications incredibly clear. (You call endpoint 416 because it's the thing that generates the authentication tokens.)

Back when I was required to train for CISSP certification (I never took the test), one section discussed the three states of knowledge--later used by Donald Rumsfeld in a rather famous quote he was lambasted for. There are things we know we know. For example, I know how to code in C. There are things we know we don't know. For example, I know I don't know how to code in SNOBOL. But then there are also things we don't know we don't know: this is why, for example, why often speakers never get any takers when he asks for questions: because his audience doesn't know what questions they should ask. They don't know what they don't know.

I think there is

Re: Professional programmer?

[Anonymous Coward]

I cracked open a dictionary and now it's broken. Imma crack open ya head now, nigga. You owe me a dictionary.

Re:Professional programmer?

[Ash Vince]

Professional programmer, noun, someone who has made programming their primary CAREER and has a recognized formal education.

There is no need to have a recognised formal education to be a good developer (although it sometimes helps you get your first graduate junior developer job). Far more useful is a few years spent contributing to open source projects and getting used to getting your code reviewed.

Once you have been programming professionally for a few years it is all about your previous roles, nobody gives two hoots about your academic background if you ace the interviews, do well on the technical tests and have at least 2 or 3 years solid commercial experience.

revision control and code reviews are essential

[cas2000]

Two of the essentials, anyway. Not enough by themselves, but necessary.

make everyone use git or similar, and have all merge requests reviewed by coders who are both willing and capable of explaining what's wrong with the submitted code AND offer pertinent, targeted suggestions for fixes and improvements.

a code review without learnable critique is next to useless. it's not an opportunity to say "fuck off, your code is shit", it's an opportunity to teach and encourage improvement in your colleagues.

This helps the more experienced coders to improve too - explaining something to someone else is a great way to enhance your own understanding.

3-hour seminar

[Latent Heat]

No. You can learn them whelps good programmin' praktice with a 3-hour corporate seminar. None of this Malcolm Gladwell ten-thousand hours of practice "stuff."

Programmin' talent comes in a can!

Re:3-hour seminar

[losfromla]

I always thought it came rolled up in a Zig-Zag.

Lol. A thing that pages people (by email/phone)

[raymorris]

That's funny; as I wrote that it didn't occur to me we used to have physical devices called pagers, though they were actually pagees (they got paged). I was thinking of thr monitoring systems that page people.

In my state

[kilodelta]

They're going like gang busters to try to each every kid how to code. I've suggested they focus on number systems like base 2, base 8, base 16. If they can handle that then you start with Boolean logic. Then open source software - python for example. It's a simple but very powerful language.

That Boolean thing is clutch though - once you understand that you're pretty much good to go. And of course some critical thinking is in order too.

It's easy

[Anonymous Coward]

You teach them. Nobody has taught three generations at this point how to be functional human beings, it ties directly into that, and for students, it is equally easy: you become willing to learn, even if said learning is the only reward you ever get for it. There are no techniques, 'life hacks', webinars , or other bullshit involved or required. Sit your asses down and *listen* for a change.

Teach aethetics and emotional intelligence

[Anonymous Coward]

Aesthetics allows us to distinguish "I wouldn't have done it that way" from "That's garbage."
Emotional intelligence lets us use the insight and experience of the rest of the team.

See http://www.elfsternberg.com/2016/12/26/care-code-quality/
http://www.elfsternberg.com/2016/08/13/programmers-class-aesthetics/
http://corgibytes.com/blog/2016/09/15/three-influential-books/
http://arlobelshee.com/gender-bias-in-my-hiring-history/

There are great ways to achieve this...

[CAOgdin]

...but they'll never see the light of day on /. Too many smart-ass wannabees flinging their feces at others...and likely to "not want to be bothered" with pre-coding design, or meaningful comments, or a "design document" prior to writing code against which the final result can be compared...and frequently updated.

Having been a programmer since 1961, I have developed lots of skills in teaching others. Having a trusted mentor is vital...someone with whom one can have a discussion, in-the-moment, about how to make decisions like "top-down" vs. "bottom-up." About leaving a trail of explanations "why" both in the code, and in all supporting documents. Good basic foundation in the principles of programming, irrespective of language, like Bohm-Jacopini...and it's variants. Practicing how to visualize a nascent program in execution, at multiple levels of granularity. All are essential...and I've probably missed a few.

Take away their cumputers

[Anonymous Coward]

Take away their cumputers so that they cannot master bait with it.

Is call seasoning.

[Anonymous Coward]

What they need is experiences. The most hated thing in programming. Tell them to do their company a favor and don't go with the flavor of the day.

most important

[Anonymous Coward]

Usability. Performance. Maintenance. Automated tests. These 5 are most important. But it doesn't hurt to know basic math also.

Well Muthu, Hm.

[Anonymous Coward]

First off, get an education, then stop going for jobs outside of an environment that YOU and shortsightedness have messed up. Stop lying. While you claim your name as Peet, we bet your colleagues address you as venkat, muthu, or shrini. There was an article some time ago about how some in a certain culture have the right to :cheat, steal, and lie all in order to perpetuate their well being, all of which derived from the statement " we have been discriminated for too long." I am not racially discriminant, but when unnecessary immigrant aggression is present within any argument, I find it hard to be sympathetic. I say welcome to California, thanks for coming by and leaving your refuse, now go home..

Thinking and Design

[mveloso]

Programmers love to program. However, the best software comes from more thinking and less programming.

Re: Why would anyone want to be professional?

[FlaSheridn]

That your comment, and its grandparent, have been modded to -1, and the parent to +2, explains all too much about the poor quality of software.

Higher Standards, Teams, Structure

[greenlead]

You help someone progress from an amateur mentality to a professional one by holding them to higher standards of work quality. This means that a programming project is properly planned out before a single line of code is written; whereas amateurs just dive in a make a mess of it. Program structure and comments are inputted logically as courtesy to your team members and others who will work on the program in the future. Additionally, there's a focus on doing the job right, rather than just diving in and hacking away until it works.

It's not about coding

[Anonymous Coward]

Don't teach them coding. Teach them how to engineer code. It's the difference between slapping something together and building something from a good plan. It's the difference between building something and hoping it'll work, and doing the math first so you KNOW it'll work.

Any large professional project needs a good plan or it'll fail. That's the difference between an amateur and a professional, at least to me.

ProjectEuler is an invalid testing tool

[gestalt_n_pepper]

Familiarity with specific fields of mathematics semantics is not the same thing as programming skill.

A good programmer can solve problems algorithmically, whether or not they know common mathematical symbol semantics. I know quite a few excellent programmers whose mathematics skills were limited not by intelligence, but by school systems that had gym teachers teaching high school algebra classes in rural communities to make extra money. Negative bonus points for those programming nerds who were bad in gym class.

All it takes is a few tricks...

[swilver]

I've been in this business for over 20 years, and I think I can honestly say that seeing my own code from one year ago, every single year, would cause me to sigh and think: "I was so naive then..."

But anyway, I wrote this book, just follow it and you'll be a professional programmer after you finished reading it...

Re:All it takes is a few tricks...

[Anonymous Coward]

TOOL

Well Muthu,,,,,,,

[Anonymous Coward]

Look, if you have to ask these types of questions here, YOU ARE NOT THE RIGHT PERSON FOR THIS TASK AND NOT QUALIFIED TO BE IN THIS POSITION. Stand aside and get qualified staff to do so..Otherwise as stated in previous comments, go home.. You cant treat Novices like pro's, quit setting unrealistic expectations. You cant teach if you dont know your subject as obviously illustrated through out the article. Blind leading the blind.Stoopid, leading the stoopid, while being stoopid.. Whats even worse, is now this individual will go out and poison the minds of a small group of individuals, all of which will FAIL, which leads me to ask "was it worth it". Person wastes time teaching a subject they do not know to people whom do not know enough to question, because there are no questions the company thinks the teacher has done their job and thus is compensated for poisoning said minds.. I would also venture to say consult your teachers/professors, to which we conjecture you dont have any which is why your filling up /. with this crap. Whats even worse the DICE EDITORS on /. allowed this crap to surface.
the vicious circle of eyes n teeth. Dont ya just love eroding credibility??

Re:Well Muthu,,,,,,,

[__aaclcg7560]

You cant teach if you dont know your subject [...]

That never prevented the gym instructor from teaching English in grade school. I had to skip high school to get a proper education at the community college.

Give them some of their own code to maintain.

[Anonymous Coward]

Ask them to write some code. Then ask them to change/maintain it. Expose them to real-life code maintenance.

The difference between a student an a professional

[Anonymous Coward]

There are a few signs that show the professional developer, such as wearing a tie.
http://www.ties.com/how-to-tie-a-tie/windsor

naive tutorials

[Martin S.]

The biggest weakness I see amongst new developers is naive approach to programming resulting from what the learn in tutorials.

The may have a good appreciate of the intricacies of the various API or libraries in question. However they complete ignore real life best practice when using them. They ignore a proper separation of concerns. The will implement three versions of the same function each with a minor differences. They will write unit tests after the fact, rather recognise they are for test DRIVEN development.

Re:Well Muthu,,,,,,,fucktard

[Anonymous Coward]

Fucktard,

you got the education you needed, bottom line. I dont see you reaching out to the community for completion of a paid project, showing your obvious ignorance..

As you exemplified, there was a lacking in your education, you sought out the right person for the right job. To that, what's this guys employer's excuse in this situation? Leveraging some peon at the lowest wages in the department, to teach everyone else???

Really??

At this point I am struggling understand the relevance of your argument as presented..
Can you help us to understand why the employer will not hire a teacher, send the students to a professionally taught workshop, or university satellite training? (all of which may be cost effective)

Mod that one.. :)

same thing you need to teach any young adult

[superwiz]

Boundaries. Both personal and professional. While both ingenuity and good work ethics are essential, they need to know that there are some rules set out by people who are just as smart, but who have a lot more experience.

OOPs and DRtW

[Anonymous Coward]

It's always the basics that get people in trouble:
- use Object Oriented logic. Why are you writing procedurally and calling it OOPs?
-- modularize. Stop trying to make your favorite framework do everything
- don't reinvent the wheel. I have an Automator who is adamant about writing test suite logic for a language that already has it. His does less and he can't articulate why the included functionality isn't sufficient
- iterate. People are waiting on your functionally: get stuff merged and integrated on a regular basis, rather than trying to get everything perfect and complete all at once

Code review

[sleepypsycho]

Where I work, everyone code reviews each others code. I find this to be the best way to propagate best practices. Novices programmers not only get comments from more experienced programmers but they also review code written by experienced members of the team. Discussions are as important as the initial comments. Code review cuts down significantly on bad habits because it is easier to fix things you know will be caught then to go back and fix them later.

Also we have reviews on code design too. This is done before writing code to prevent rewriting everything that is already submitted.

Re:Professional programmer?

[Aighearach]

Your post basically says, "Golly, I don't know what all these big words mean, maybe if I make it up none of these dumb slashdotters will ever have read a dictionary?"

If you're going to engage in a No True Scotsman, at least look up the etymology of Scotsman and make yourself worth correcting.

You define "business" to the idiotic dev lead

[gestalt_n_pepper]

In facility architecture, there are architects, building programmers, estimators, schedulers, carpenters, bricklayers, plumbers, electricians and general laborers.

In large scale software, there are architects, developers, testers, tool builders, UI specialists, configuration management engineers and so on.

You don't expect the carpenter to do what the plumber or the head architect does. Neither should you expect the tool builder or UI architect to do what the system architect or feature lead does.

Workers in every field have varying levels of skill. Don't expect the scripting guy to suddenly embrace the wonders of the factory pattern. It's not his job and he's not interested.

What a dev lead who's worth a shit should be thinking about is getting the best labor at the cheapest price to get the job done, and stop trying to hire a system architect when a scripting guy will do.

Software is business, not art. Do that on your own time.

Re:Well Muthu,,,,,,,fucktard

[__aaclcg7560]

Fucktard,

Sorry. I don't know your mother.

At this point I am struggling understand the relevance of your argument as presented.

I could say the same about your comment.

Mod that one.. :)

I could say the same about your comment.

Does training really pay a lot better?

[Paul Fernhout]

"Now, I've gotten old and I decided I liked money a lot, so I left my job as a programmer after nearly 20 years and moved onto being an network instructor."

Thanks for the interesting programming career story and perspective which obviously reflects a lot of talent, hard work, and success as a software developer. While training is important and well worth doing for lots of reasons, I still don't quite follow from your story how a move to training would pay significantly better than programming?

Example for the US:
https://www.indeed.com/salarie...
"Average [hourly] salary: $17.60 [with the tail going up to around $50]"

Granted, sometimes people run onsite training seminars for tens of trainees for totaling thousands of dollars a day (sometimes less hotel conference room rentals and travel expenses etc.). So maybe that is your angle? But even, say, 50 training sessions a year times $5K each is only $250K gross revenue, less after expenses, and travelling can be tiresome -- so overall still seems iffy to me compared to programming in a well-paying position or on an independent (successful) project.

That said, I've enjoyed the times I've taught other people things related to computers, so I won't deny the general appeal -- especially later in a career.

More Professional?

[Neuronwelder]

Have them wear a 3 piece suit.. Well, they believe that that stunt works at the White House!!

Interesting. Perl wantarray(). Useful as a functio

[raymorris]

That's interesting. I can't quite decide if it's useful or goofy. Maybe both. I've done something similar when it makes sense - very recently in fact.

Once I saw this program, with a whole company based on the program, which accepts absolutely anything as free-form text input, or even voice and pictures. If the input resembles a mathematical expression it returns the result of evaluating the expression. Even math with words like "5 grams in ounces". If you give it a picture as input, it returns similar pictures. If you give it input that resembles an address, it returns a map to that address. This strange program, called Google, has been moderately successful.

Extending your idea a bit, rather than copy-pasting those lines, one could have it as a function get_arg_objects(). Yes, it would be a very short function. The Linux kernel uses very short functions like that, and Linux is a tad successful. In fact, many C, perhaps most, programs use one-line functions like that - they call them macros.

Your code reminds me of a strange function in Perl called wantarray(). It allows your function to return different types, depending on that the caller seems to want. So you can easily handle of these appropriately:
My_number = foo(bar);
My_array_numbers = foo(bar);
foo(bar);

Scare them a little...

[Anonymous Coward]

Tell them some really bad stuff could happen...because it will.

This is the wrong question

[Anonymous Coward]

You cannot "make" novices professional. They must be driven from within to become professional themselves. A better question would be, "How do you inspire novice programmers to seek knowledge, experience, and proficiency as desperately as they want to breathe?"

Buy this idiot a dictionary

[Anonymous Coward]

The only way to turn someone into a professional is to pay them. A professional, regardless of his skill, is someone who gets paid to do what he does.

Teach it as a trade

[scorp1us]

The college curriculum is focused on how to get software to work - at all. You do project that are supposed to do things. And you get your program to work, you submit it, and if it passes the tests, it "works"

However in the real world we are no longer concerned with getting software to work. We assume that it will be developed and will eventually be working, through some majority effort of feature-adding and a minor part maintenance, it will be accomplished. But what makes that assumption possible is that good code is written from the start. New developers will write terrible code - but it will work in the average case. To write "good" code, requires an insight into how software fails. Young developers only know how their software fails in the few ways they've been able to encounter because that's all they've seen.

So my proposal is to treat software development like a trade:
Apprentice - Write tests for code for journeyman or master developers. See all the ways that software can work AND FAIL. Minor feature additions, scripting, DevOpsy-stuff. Can write code for limited internal apps, and production systems but only under supervision. Will develop proficiencies with technologies. (AKA Jr Dev)

Journeyman - Armed all the ways the software can fail even by more experienced developers, the engineer is now able to write code for production systems. Unit tests are written by an apprentice. Demerits for when an an apprentice finds a bug. (AKA Sr. Engineer)

Master - this isn't really a thing because Journeymen are expected to move into engineering management -- if they want to.

More professional? You gotta be kidding

[bearvarine]

Lets face it. Software development is a ruined field. It is full of irritating bloviating self-important hotheads who think their way is the only one true way. It is a ruined field of endeavor, because if you think software development requires the discipline of other science and engineering degrees, then why is there no licensing exam? Answer: software development is more art than science or engineering. Because it is more art than science, software development is tribal in nature -- each company nurtures and promotes its own unique way of brewing completed projects.

Make Them Want It

[Anonymous Coward]

Make the novice programmers want to improve.

If you do that, all the rest will follow. Fail to do that and you're just pushing a rock uphill. You can get improvement against the novice's will but it will always be difficult and progress will be unsatisfactory.

You've got 3 hours? Inspire them. No lectures, no content, just inspiration. Then at the very end tease them with sources they can follow on their own.

Hit them over the head,

[cwsumner]

Hit them over the head with Murphy's law.
In other words, make them use, test, debug and fix their own software.
Also make them test and debug other people's software.

My Navy electronics teachers had stores of carefully defective equipment, just for us to troubleshoot and fix.
So, bring some carefully defective software for them to test and debug. Grade them on how many bugs they can get fixed! 8-)

Colleges teach a lot of analysis and design, but little (if any) troubleshooting and repair. (Except in local 2 year technician courses ... maybe.)
But you cannot design like a professional if you cannot see what will go wrong.

Of course, it's harder to grade it... 8-P

One rule:

[selfandother]

Test. Before. Committing. You break the build, you don't go home until it's fixed.

No fast method.

[Anonymous Coward]

I think you can turn someone into a professional programmer in two years.

Step one: make them write some new function or form for your users.

Step two: make them do user support for two months (and rewrite the form as needed)

steps 3-9, make them work on some other programming modules, revising what other people have written.

Step 10: After two years, make them update the form they wrote originally.

Re:Professional programmer?

[Archtech]

I am appalled that this thoughtful and reasonable comment has been moderated down to -1. Maybe Slashdot is a waste of time.