Ask Slashdot: How Would You Teach 'Best Practices' For Programmers? 220
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?
Learn math (Score:5, Interesting)
Re: Learn math (Score:4, Insightful)
Imho grammar is at least a important as math. If a person speaks like an illiterate rube, chances are he'll program like one too.
Re: (Score:2)
A student should have an uncluttered mind. A mind that is cluttered is a sign of someone impatient and lacking in self-discipline.
Have a programming apprenticeship program where the student writes code and the "advisor" reviews it for correctness, completeness and style. At first once per day review, then once very two days, to once per deliverable.
Most of all, the student for a few weeks, be given ample time and low priority tasks, and as the skills improve, tighten up the student's timeframe to deliver.
Re: Learn math (Score:2)
Histories, by Herodotus
Natural Logic, by Neil Tennant
Twilight of the Idols, by Nietzsche
Re: (Score:2)
And yet your "witty" retort itself contains a miscapitalization. Perhaps an illustration that:
a) typographical errors != grammatical errors
b) text input on a mobile device is prone to typos
and
c) Slashdot's mobile interface sucks donkey balls
Re: (Score:2)
Re:Learn math (Score:5, Funny)
I think a combination of the "Wizard of Oz" approach and Cognitive Behavior Theory would be very effective here.
Never seen a great developer without strong analytical skills.
I've never seen great developer, or actually, someone who thinks that he is a great developer, who didn't look, smell and act like one.
Do not shave your neck any more.
Stuff yourself with unhealthy junk food; preferably, while working at your keyboard.
Think that you are a super-genius and all your colleagues are idiots. Convince yourself that your code never has any bugs, and the problem must be somewhere else.
Showers and baths? Forget it. The whole world is in a drought, and you need to save water.
Get yourself into meaningless arguments about trivial things like vi vs. emacs. Refuse to stop arguing, even when everyone else has left the room.
In short, you don't need to be a great developer! Just play one on TV!
Re:Learn math (Score:5, Insightful)
Always break down the problem into small parts that are easy to manage and test.
Re: (Score:3)
Get yourself into meaningless arguments about trivial things like vi vs. emacs. Refuse to stop arguing, even when everyone else has left the room.
God intended Man to put the opening bracket on the same line as the if statement. No corporate drone's so-called "standards" can convince me otherwise.
Re: (Score:2)
Re: (Score:2)
And why do you write Math in your subject line but talk about analytical skills in the comment?
Math != Analytical skills
Re: (Score:2)
And why do you write Math in your subject line but talk about analytical skills in the comment?
Math != Analytical skills
That's what I was wondering. I imagine there is a reason that development uses the word "architecture". Design is often about understanding where and how to make compromises between contradictory requirements. And didn't IBM originally think that programming was something like music composition? Which is not to say that some problems are not extremely mathematical, just that that is one form of cognition, and there are other intelligences which come up in other problem types. So perhaps the question is a bi
Re: (Score:2)
Architecture is the combination of known design elements to meet a particular use case.
Engineering is design based on mathematical calculation of all the strengths of the necessary materials.
Software can be created using either of those systems, or using almost any other creative pattern or procedure.
Code is normally designed as in architecture, but sometimes (spaceships and traffic controls) it is engineered.
You don't actually need to learn how to "do" math in the sense that they mean it in math classes, w
Re: (Score:2)
Actually we agree what "best practices" are.
You can google for it and then you find the 5 steps/levels of CMM(I) which are centered around about best practices.
https://en.wikipedia.org/wiki/... [wikipedia.org]
The question however is for a single developer which of the best practices he should know. That is why we developed agile methods like Extreme Programming (XP) and Scrum, to focus on the stuff that is relevant for a single developer so that others can focus on the bigger picture (like acquisition, planning etc.)
Re: (Score:2, Insightful)
Logic is a branch of mathematics.
Re:Learn math (Score:4, Informative)
Other way around - mathematics is a strict subset of logic, which also applies to realms well outside mathematics.
Re:Learn math (Score:4, Insightful)
There is no problem finding good mathematicians that knows jack shit about logic
Name one.
Re: (Score:3)
There is no problem finding good mathematicians that knows jack shit about logic
Name one.
Hey, now... you can't just go around demanding that random people on the internet be ready to back up their claims with sources, or facts even.
Re: (Score:3)
Correctness and performance are directly tied to logic.
"Sadly, this is why programming is still an art"
That is not sad at all. Musical theory requires understanding some physics and mathematics. No one would ever despair at the thought that great musicians are creating art.
".. using the two in the same sentence is disrespectful to logic."
That very sentence lacks the latter. Do you think that logic is offended?
Re: (Score:2)
No argument that math is taught in a way that only seems to really "click" with the minority of people that already think in a way suitable to become mathematicians (aka extremely theoretical logicians) within the current framework - which is a shame, because regardless of whether you're suitable to become a mathematician in *any* framework, math is beautifully elegant, and being able to effectively use math to solve the relatively simple problems in life, engineering, etc. is immensely useful.
I think the v
Re: (Score:2)
I agree - seems like recently especially we've gone the way of "shortcuts to make doing arithmetic easy", which strikes me as utterly ridiculous. Calculators are everywhere, and do arithmetic faster and flawlessy. Use those for applications, and focus on teaching the basic principles that work everywhere and form the basis for further learning.
My point with proofs and theories was perhaps badly expressed, it had nothing to do with errors. Math and Science are much more fundamentally different.
First, lets
Re: (Score:3)
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
Back to basics (Score:4, Insightful)
Indentation and comments.
Stopping for a moment to ask yourself if you NEED to load a 50 MB library for two lines of code.
Re: (Score:2)
Indentation and comments.
And many so called comments are a no-no. New programmers comment the steps in the procedure and they shouldn't. The code itself is supposed to be the documentation of the procedure. Name your variables and functions appropriately, refactor down large functions, and document the damn data.
Re:Back to basics (Score:5, Insightful)
Oh hell no. So-called “self-documenting code” isn’t. You can write the most comprehensible, clear code in the history of mankind, and that’s still not good enough.
The issue is that your code only documents what the code is doing, not what it is supposed to be doing. You wouldn’t believe how many subtle issues I’ve come across over the decades where on the face of it everything should have been good, but in reality the code was behaving slightly differently than what was intended.
Re:Back to basics (Score:5, Insightful)
The issue is that your code only documents what the code is doing, not what it is supposed to be doing
Mod this up. I aim to document my intent, i.e. what the code is supposed to do. Not only does this help catch bugs within a procedure, but it also forces me to think a little bit about the purpose of each method or function. It helps catch bugs or inconsistencies in the software architecture as well.
Re: (Score:3)
The issue is that your code only documents what the code is doing, not what it is supposed to be doing.
You can document that with good names. No need to add comments that are likely to become actively misleading.
Javadoc-style comments are useful (and, actually, if you're writing appropriately-small functions provide all the space you should ever need for documenting the rationale), but inline comments are a code smell. If you feel the need to type a comment explaining what a small block of code does, that's a hint that the block should be factored out so that you can name it something that documents its pu
Re: (Score:2)
I remember in `99 printing out all the C headers for Gtk+, because it was better documentation than whatever existed for the Perl bindings I was using.
Yes, when the code is well written enough, like Gtk+ 1.0 was, then that is all the library user should need.
Re: (Score:2)
Self-documenting code can make it easy to see what the code is doing. It doesn't describe what the code is doing, or why. That's what comments are for.
Comments that don't tell you anything the code doesn't are mostly useless. Worse, someone will change the code and forget to change the comments. Comments that tell what the code should do are a lot more stable.
Re: Back to basics (Score:2)
Re: (Score:2)
Comprehension fail.
"document the data" with comments != no comments.
Unless you have no data. In which case you're very lucky, because you also have no bugs or misfeatures.
Re: Back to basics (Score:2)
Re: (Score:2)
I once wrote a library for (essentially) GIS which was full of comments that were 20 lines or longer. When the correctness of the code depends on theorems in non-Euclidean geometry and you can't assume that the maintainer will know any, I don't think it's a bad idea to make the proofs quite explicit.
Re: (Score:2)
Sometimes I'd rather they load a well tested, robust 50MB library that try to write it themselves.
Naming is where most programmers go wrong. I have some rules, like putting the units in the name, and am not afraid to re-factor if it makes something's function clearer.
Re: Back to basics (Score:2)
She tried to refactor your comment but lost part of it on the way.
Re: (Score:2, Insightful)
Don't comment your code. Code your comments.
Re: (Score:2)
Yeah, and the library is guaranteed bug free and optimized for your needs -_-
If like above, it's literally a few lines of code, just write them, if a bug is ever found in them fix it (i'd prefer having to fix an error in those couple of lines of code (and then adding a test making sure it never happens again), over losing hours when something is going wrong in the library and that being a lot harder to do something about/work around it)
Using a library is always a trade off.
Re: (Score:2)
Agree. The footprint is negligible vs the headache. If you've chosen well and leveraging your library correctly you shouldn't need more than one.
Re: (Score:2)
Oh, yea npm...well all I can say is tough shit. Do a rollback and what till its fixed or switch to yarn in the meantime, womp womp, life goes on. If you really want to be fair, that could happen to lots of package managers. And if you don't do backups for globals and source control you have bigger issues.
Team skills (Score:2)
bottom up is best. (Score:1)
One should start with assembly language, machine code, or even gate layouts. Higher level languages evolved as a pile of shortcuts and safety measures on top of this, and programmers should understand what is being shortcutted or protected against and why.
Once you've learned from experience all the terrible mistakes you can make in assembly, and learned the self-discipline not to make those mistakes ever again, you are ready to move on to the next level.
Re: (Score:2)
Nope. Start with a usable language. Higher-level languages evolved as abstractions over the machine code, and the abstractions are very useful. The hard part of programming is taking an informal problem statement and turning out an accurate formal solution, and that's enough to learn on its own without worrying about which register has what.
Not that difficult to say but hard to do (Score:1)
1) There are always things to learn
2) KISS
3) If it can go (and it will) wrong then test for it and handle the error.
4) There is no one solution for anything
4a) There is no one RIGHT solution for any problem. There are always different ways to skin the cat.
5) Never act like you know it all even if your name happens to be D. Knuth. (joking)
6) Read, ask, read, ask and then think. Think again before you even start to think about coding.
7) Don't be afraid if your first solution is crap and really does not work v
Re: (Score:3)
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".
Re: (Score:3)
Point 5 could be strengthened. Don Knuth doesn't act like he knows it all (source: personal experience), so certainly no-one else should.
Fuck Off With Your Workshop Bullshit (Score:2, Insightful)
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 i
Be a team player (Score:2)
When they arrive, slap them hard on the back and then look them in the eye and say in as sinister a manner as possible.
"We like team players here, Nugget. Are you a team player?"
Emphasise the words 'team' and 'player'.
Then walk off.
Also have a broken build bear
http://www.vikingcodeschool.co... [vikingcodeschool.com]
Be ready to break things. Sometimes things get through QA, sometimes you break the build. A lot of times that will get caught in your continuous integration systems and testing and everything like that. But sometimes even you just push production, like bad code to production, so you're going to break stuff. The most important thing I can say from day one is to know how to fix it. Know how to back the changes out, know how to do things that can undo the damage that you do and then just accept it. It happens, we have a "broken build bear" that we pass around our office for people that do it as a shaming mechanism, but it's mostly in good fun. But it is important to sort of know how to undo.
Electric shocks (Score:5, Funny)
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.
CERT Secure Coding Standards (Score:2)
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/... [cmu.edu]
Apparently they them for other languages like C++, Java, Perl.
at a University? (Score:2)
Easy (Score:3)
a whole "half a day", eh? (Score:2)
If that's all the time you've got, you've got a systemic problem. This kind of thing needs to be an ongoing process of education. You can't cover anything like this in half a day. Or a full day. WTH.
Schedule "brown bag" sessions once a week for ongoing training and discussion, and get subject matter experts in for different things: security, TDD, algorithms, optimization, etc. And keep going; don't just do each of those once, because each of those is a full course full of stuff (at least).
If you're only goi
Impossible (Score:2)
I don't think there's a reliable way to teach programmers best practices. Programming is like composing music: you can teach all the rules and be a technically perfect musician but in the end the real difference between a good programmer and a bad one is elusive. The trick is not to teach programmers, the trick is to find them.
Re: (Score:2)
Of course there is.
Just like for composers. For composers you would assume he can play at least one instrument or can use music programs good enough to compose tracks that sound not to bad.
Same for a programmer, he should be able to use his tools properly, like a version control system and a build system and depending on organization know about continuous integration etc.
Then probably comes a ticket system. And learning how to pick up requirements, aka Use Cases or Stories or more technical requirements in
Re: (Score:2)
You wanted to disagree with it, you really did!
But you don't seem to have understood the point.
Instead of getting hand-wavy and dismissing the idea that good composers can't be reliably taught, consider first the ways in which it is true. Then you can understand the points being made, and when you go to argue with them, you'll succeed at finding them! Instead of just talking past them and arguing from ignorance.
Hint: that a competent musician might not be able to write anything that sounds good even on that
Re: (Score:2)
Composing is more an art, and the composer has ofc to accept the judgement of his audience.
The internal quality and external quality of a piece of music is the same.
Programming software is just a craft (yes, you can drive it up to higher levels and the highest might be art ...) as long as the software passes a test (probably automated) it is fine.
The internal quality and external quality of a piece of programming is not the same. The software can look from the outside perfect, my be even perfectly useable.
Ask Slashdot: How Would You Teach 'Best Practices' (Score:2)
I've been asked to put together a half-day workshop whose title is "Thinking Like a pimp."
I've been asked to put together a half-day workshop whose title is "Thinking Like a police."
I've been asked to put together a half-day workshop whose title is "Thinking Like a plumber."
Why not, while you are at it?
Re: (Score:2)
And which of your workshops was the most successful? I like to join it sometimes, perhaps :D ...
Well, the pimp thing probably not
Re: (Score:2)
Half-day workshop on Thinking Like a Pimp, targeted for theater beginners.
1 hour vocabulary study with dialog practice.
1 hour study of misogynistic tropes with role-playing exercises.
[break]
1 hour of gait study and exercises
1 hour of costume study
Method study not recommended.
Re: (Score:2)
The opposite of feminism is machismo, no more, no less.
You are an hopeless baizuo.
Where to begin? (Score:2)
Re: (Score:2)
1) I guess "coding" is just the new word everyone likes to use because it sounds cool, so yes, it is programming. ... the programmers of the web server will ... and those are likely 2 or 3 levels
2) Race conditions by definition only happen in multi threaded systems. And plenty of software is not. Your examples are wrong. A web server will be multi threaded, but most of the time will only use exactly one thread per request. In other words, the programmer of the web application will never see race conditions
Re: (Score:2)
2) Actually it's not uncommon at all as a web developer to have a problem arise because two people are viewing a website at the same time and the two threads make database alterations in the wrong sequence. You have to be aware of it and make decisions about how to handle it.
Re: (Score:2)
Sorry, that is not how databases work ;D
Re: (Score:2)
lol if you don't think you can have a race condition in single-threaded code, wow... that's what I call "sheltered."
Doing consulting work it isn't even surprising or uncommon.
Race conditions are any time the algorithm relies on things happening in a certain order without checking. So any type of non-blocking read, for example. Or you might have to set some system register, and then wait for some other register flag to show up before doing the next step. Screw it up and you've got a race condition.
I had one
Re: (Score:2)
lol if you don't think you can have a race condition in single-threaded code, wow... that's what I call "sheltered."
No you can't.
So any type of non-blocking read, for example. Or you might have to set some system register, and then wait for some other register flag to show up before doing the next step
That is nonsense.
I had one a few weeks ago where an interrupt service routine simply made a faulty assumption about the maximum number of cycles it could take to start
That is not a race condition.
Interestingly
i need this! (Score:2)
I think you mean standard practice (Score:3)
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.
Find the errors and fix them strategy (Score:2)
Teaching people by showing them errors or bad code doesn't move the needle very much. In technical subjects I prefer to used researched based teaching strategies. Put attendees into groups, give them bad code examples, and have them find the errors or ways in which the example could be improved. Then have a discussion about it and guide them all to a common understanding. If you show someone a bad example or give comments for improvement, it typically goes in one ear and out the other, if they find the er
Teach the process (Score:2)
From my experience of answering tons of questions on StackOverflow, a huge deal of newbies or self-taught programmers program the following way:
- try some random thing
- get an error
- ask how to fix the code (and not even post the error)
You should teach them the right process, which is based on reading (a lot), experimenting, analysing errors, making deductions on what needs to be changed, and repeating the cycle:
- read documentation, before starting programming. You need to u
Re: (Score:2)
Organization is key - both within a file and across the whole program - to letting anyone else understand your code. At the project level, try to make it obvious how the project is structured by choosing appropriate names and, if it's a large-ish project, break it up into folders in a logical way and provide a readme.txt that tells readers about the main parts of the project, where they are located (files and names of types/classes) and how they fit tog
Programming is easy if you already think like one (Score:2)
Good programmers can identify the real problem underlying the problem that is presented to them. Most projects (in any field - not just programming) are poorly specified and don't have well defined requirements. Think of the Obama-care website or pretty much any government construction project.
If you are good at predicting possible mechanisms for failure, programming is easy.
Re: (Score:2)
All of this.
But as a self taught programmer who works in education I'd love a half day or full day of hands on learning of how to use git and other version control systems
I'd go with the specifics of being self-taught (Score:2)
I don't think you can teach then to write "better" code, like the actual ability to break an task into programmatic steps. While you could learn some useful algorithms and patterns that's a long topic and more something you get with experience. What I would focus on is a self-taught programmer has probably mostly worked alone, written all the code themselves and done relatively small projects with a limited lifespan and a lot of greenfield projects where you deliver version 1.0 in the end. This may not be t
Sytematic program design. (Score:3)
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... [amazon.com]
I recommend you check it out and google the course name.
Good software development (Score:2)
1. When a bug is reported in a group project, there are 2 types of people.
1.1 Without any investigation, a developer declares that it isn't his/her problem.
1.2 A developer who assumes it might be his/her problem and starts investigating.
I certainly prefer the latter. This isn't about ego, it's about code doing its intended job.
2. Developing always creates bugs.
Prolific developers create lots of bugs.
Developers should not be judged on the n
Hahahaha, fail (Score:2)
If you had half a year, it would be doubtful you could achieve much. Half a day is a complete joke.
Sanitize input (Score:2)
Be aware that other people cannot read your mind (Score:2, Informative)
If the answer is "yes":
Basically, never assume that checking in code is the final step
Humilty, but you can't teach that (Score:4, Interesting)
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.
Re: (Score:2)
My best advice for "being a good programmer" doesn't have anything to do with writing code. One of my professors taught us to "define, defend, and attack" something to show you have a solid understanding of it. Another lesson I've learned is to never come to a manager/leader with a problem. Come to them with a problem and at least 3 well thought-out solutions. I've really taken these lessons to heart in my career. Going into a design meeting, concisely and thoroughly explaining the problem and being able to
Software Carpentry (Score:2)
You could take a look at what Software Carpentry https://software-carpentry.org... [software-carpentry.org] teach. They cover relatively practical skills like version control, regression tests, etc. which are still a big step forward for many research programmers.
At a more conceptual level you are aiming towards "abstraction" and "separation of concerns". Self-taught academic programmers are usually quite good at getting individual methods to work, but hopeless designing software so that changes are localised.
Me code pretty some day (Score:2)
Me code pretty some day
A voice in the wilderness
http://world.std.com/~swmcd/st... [std.com]
The Elements of Programming Style (Score:2)
https://www.amazon.com/Element... [amazon.com]
Maintenance and Support (Score:2)
Teaching explicitly what experts hold tacitly (Score:2)
Avoid cargo cult programming (Score:2)
A couple ideas (Score:2)
I would say the first best practices is to make code easy to read. That would include:
- Syntax formatting all the indents and whatever case things are popular for variables, globals, functions, etc.
- Breaking out of command packing lines, Indenting, how you present opening and closing brackets/braces/parenthesis
- Descriptive naming of tables, fields, variable, functions, etc.
So when you are done comments wont be apologizing, but just augmenting what is apparent. Once much of that is done class should star
Think like a hacker (Score:2)
Address The Lack of Formal Training (Score:2)
This workshop's intention is to address this lack of formal training. Why not provide them with formal training (CS degrees?) if you want to address their lack of formal training?
These are other science people, right? (Score:2)
From personal experience (Score:2)
Having dealt with a lot of code (and programmers) who came from other backgrounds (EE or math), here are the top things I would try to teach them:
1. Data structures and interfaces. Too many of these people create a sea of global variables and functions that manipulate them in difficult to follow ways. Discourage global variables in general except for constants because they WILL abuse them. If you get them thinking in terms of data structures and interfaces (and thus subcomponents of the problem) it will
Re: (Score:2)
Software Design Principles (Score:2)
You should probably start with Software Design Principles:
DRY (Don't Repeat Yourself)
KISS (Keep It Simple, Stupid)
YAGNI (You Ain't Gonna Need It)
SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation, Dependency inversion
Then plan on having a lot more of these meetings, because you should not be able to adequately cover these principles in a half day. Afterwards, you should probably also have meetings on coding standards, methodology (waterfall, agile, or whatever), testi
Have worked in similar environments (Score:2)
I've worked as a developer in similar environments - where there are a lot of smart people with a background in math, physics, EE, or aerospace, who've googled their way to a moderate level of programming proficiency (they can probably hack together a script to do just about anything) but have zero understanding of code style, modularity, maintainability, or quality.
Some of the things that I wish everybody understood:
Very basic ideas about rules of thumb and sniff tests for maintainability and readability -
Mark Twain described some useful approaches (Score:2)
There are nineteen rules governing literary art in domain of romantic fiction -- some say twenty-two. In "Deerslayer," Cooper violated eighteen of them. These eighteen require:
1. That a tale shall accomplish something and arrive som
Communications skills are everything... (Score:2)
It's not about programming: engineering reliable computer systems is about how you work with the organisation and people around you to deliver, to prove you've delivered, and to keep alive your system.
If you don't understand your code well enough to teach it to anyone -- especially those less technical, educated or experienced than you -- you don't pass review.
If you don't practise for critical incidents -- which firefighters and emergency-response teams do -- you'll make that unexpected bad day a whole lot
Re: (Score:2)
Agreed. And in the same vein, good comments that concisely capture the *intent* of the code. What exactly the code does is usually pretty self documenting*, nobody needs "assigns 5 to x" style comments, but *why* it does it, what it's trying to accomplish, is often much less clear, and discrepancies between the intent and the reality can often highlight bugs
* there are times when it's good to document *what* code is doing, usually in the case of the occasional bit of performance-boosting cleverness (magic
Re: (Score:2)
Not constraining the language is the worst error you can make. New programmers and fledgling developers tend towards the newest bright shiny object... which often cannot really do the job.
Five years ago, many "developers" who had been at large companies but never a crucial part of an existentially-important project, such as at a smaller company where completing and shipping functional software matters, jumped onto the Node.JS bandwagon for micro-services. Node is single-threaded, doesn't have good type saf
Re: Condescending much? (Score:2)
Testing. IME, most self taught programmers have no idea how to write tests or use a testing framework.
That's easy. If it compiles, it passes the first test. If it compiles without warnings that's like an A+.
For the second test just put it into production and see if anyone complains.