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?
Let them accumulate experience and wisdom, and when they achieve it then tell them they're too old to work in this field.
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.
I'm a consultant - I convert gibberish into cash-flow.
Find some good source code for them to study
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.
Make them read at least some of these books.
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.
"First they came for the slanderers and i said nothing."
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.
> 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?
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"
Next article, how can I make a baby walk like an adult
How about paying proper experienced people, and put them orienting your newbies?
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.
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.
I agree on the examples and discussion around them.
... 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.
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
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.
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.
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
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
> 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.
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
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.