Slashdot Mirror
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?
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?
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.
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.
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
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?
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
I blame the puzzle-question job interviews for the rich variety of clever code out there that is hidden behind horrible user interfaces.