Slashdot Mirror
Ask Slashdot: How Would You Teach 'Best Practices' For Programmers?
An anonymous reader writes:
I've been asked to put together a half-day workshop whose title is "Thinking Like a Programmer." The idea behind this is that within my institution (a university), we have a vast number of self-taught programmers who have never been taught "best practices" or anything about software engineering. This workshop's intention is to address this lack of formal training.
The question is, what should be covered in this workshop? If you have an idea -- that also has an example of best practice -- please share!
It's really two questions -- what "thinking like a programmer" topics should be covered, but also what examples should be used to illustrate best practices for the material. So leave your best thoughts in the comments.
How would you teach best practices for programmers?
The question is, what should be covered in this workshop? If you have an idea -- that also has an example of best practice -- please share!
It's really two questions -- what "thinking like a programmer" topics should be covered, but also what examples should be used to illustrate best practices for the material. So leave your best thoughts in the comments.
How would you teach best practices for programmers?
There is no way around it. Never seen a great developer without strong analytical skills.
Indentation and comments.
Stopping for a moment to ask yourself if you NEED to load a 50 MB library for two lines of code.
-=This sig has nothing to do with my comment. Move along now=-
The basic summary is: you don't know how to code or you would know it takes a decade of trial and error to get good, even after learning the basics. It's sure as shit not going to happen in a half-day workshop and teaching "best practices" will at most create a zealot who doesn't know what the Hell they are doing and is adamant about not learning. Code workshops don't work, best case scenario you're a lazy low-or-moderate-ability programmer, worst case you're a marketing hack.
TL;DR: Stop tricking idiots into giving you money, you parasite.
The most efficient way to teach best practices is to give the programmer electric shocks for every error, and more for bugs caught in testing. For approved commits you may award them with treats.
- Raynet --> .
Start with the CERT Secure Coding standards, especially for C programmers it covers many of the "gotchas" to watch out for.
SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition)
https://resources.sei.cmu.edu/...
Apparently they them for other languages like C++, Java, Perl.
With a bat.
Stumbling towards a steaming pile of shit with flavor of the day development strategy, flavor of the day framework and flavor of the day lingo and absolutely never with any structural ways to avoid the most common security flaws we have been aware of for multiple decades. That's what you have to teach them.
They want a job, knowing best practices isn't conducive to that.
A couple of years ago I took a MOOC called "systematic program design."
Even though I was a self tough programmer and had been programing for 25 years,
i still learned something new.
They used this book
https://www.amazon.com/How-Des...
I recommend you check it out and google the course name.
If the answer is "yes":
Basically, never assume that checking in code is the final step
we have a vast number of self-taught programmers who have never been taught "best practices"
Arrrrgh! The worst sort.
These people tend to be rank amateurs. But with the "experience" that makes them think they are actually professionals. Almost none of them are. And most never will be.
Most people, even people who make a living from programming, are much worse at it than they think they are. They are impatient, they are hit-and-miss, most can't think clearly and an unfortunate number share in the twin misconceptions that "if it compiles cleanly, it works" and that testing is merely a stage that comes between coding and release to production (and is not there to fix problems, merely to tick boxes).
Personally I would focus this workshop on the cost of the errors made - and target it at the senior people there. Drum it home that "good" software - best practices is not about how many million lines of code you can write in a day, nor about how complex you can make an algorithm. It is about being able to hand your work off to others and the ease with which they can understand what it does.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
9. Distrust your darlings - if you've done something very clever that you're quite proud of, it's probably a good idea to give it a good hard looking over with a critical eye (or better yet, have someone else do so), and see if you haven't made a grossly over-complicated solution in search of a problem, when something much more straightforward could do the job better.
I'd disagree with (6) though - it needs more thought between "read" and "ask".
--- Most topics have many sides worth arguing, allow me to take one opposite you.
During the 1980s, there was much research into the psychology of experts and that included programmers. Soloway et al found that experts exhibit tacit problem solving skills that they apply automatically. I completed research work a few years back looking at the effects of teaching such skills explicitly to novice programmers. If you're interested, here's a good starting point... http://crpit.com/confpapers/CR...
Point 5 could be strengthened. Don Knuth doesn't act like he knows it all (source: personal experience), so certainly no-one else should.
They fail at math, not because they are bad, but because
Oh, in many cases they fail at maths because they are bad.
It's politically correct to pretend that there is no such thing as aptitude and that everyone is equal. This is a blatant lie, and everybody knows it's a lie, but everybody plays along, because either you benefit from the lie, or it is the least dangerous move if you value your future and career opportunities.
I worked as a maths tutor for people who struggled, and in some cases, they had not been properly taught the underlying fundamentals and "seen the light". Those were very teachable; finding out just where the blockage was would generally lead to going through years of missed teaching in weeks.
Others... lacked ability, and the job was making them do the most of the abilities they had, and perhaps become good at particular tasks. But they would never understand it and intuitively be able to apply it for new situations, just be able to do tasks.
Much like a colour blind person can never truly understand the colour differences he (most likely) isn't seeing, someone without the ability to see the logic and abstractions of maths will never truly understand what she (most likely) isn't seeing. Yet both can function well in society despite their handicaps. But part of that is acknowledging that there is a handicap, and that the correct response then isn't go give up and blame the handicap like too many do, but to learn to compensate for the handicap as much as possible.
As for aptitude deficiencies, they vary, and seem mostly based on different levels of abstraction. While most are able to understand concepts like calculus or dimensional transformations, some struggle. A few have a hard time with algebra and statistics, and yet others are unable to intuitively grasp a concept of zero. At the other end, a majority seem unable to grasp relativity, and especially being able to abstract time as a local phenomenon where words like "before" and "ago" loses all meaning.
Teaching can help people cope with the different levels of aptitude, but not change the underlying brain any more than you can teach someone to distinguish colours they just cannot see.