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=-
I am talking from my old days. When I was at university, most of the things I did was on my own. However, in the real world, it is hard to see a single person carrying all the burden and responsibility of a project. Team skills are important if you want to get out of your mom's basement.
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.
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 very well. Learn from that and make it better next time (difficult with Agile and reluctance to sort out Technical Debt)
8) Trying things out is not a sin.
There are dozens more but you would be surprised at how many recent grads know 'none of the above'.
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.
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...
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
1) The art of commenting
1a) What are good identifier names
1b) Why magic numbers should always be avoided
1c) When, why and how to use comments
2) The importance of unit tests and what they are
3) The importance of modularity
Then, to get them to *really* appreciate why these are important, have them look at a program loaded with magic numbers, bad identifier names, lacking comments, huge source files and no unit tests. Have them chase down a bug for a while in that source code. Give them a deadline for additional fun.
Don't you have any Comp. Sci. professors there? There job is to teach students how to think like programmers (as opposed the "learning to code" that gets so much press coverage).
With a bat.
People need to learn themselves what is good style to write code. Pushing whatever you consider to be good practise is very bad, since it steals the students the experience to learn the stuff themselves, and thus they wont have proper reasons why some practises are bad. Once they've seen it themselves, they can make the right choice in every situation, but if you push it to people, they don't know _why_ the recommendation is important.
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 going to get one day for this, collect a bunch of online resources for people and go over it. Then find a job at a place that values ongoing education, because HOLY CRAP. How can a *University* not value ongoing education?!
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.
0x or or snor perron?!
I've been asked to put together a half-day workshop whose title is "Thinking Like a surgeon." ... ... ... ...
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?
I don't know sign me up! Seriously I need this.
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.
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 errors themselves, according to research they are less likely to make those errors again.
Take a read through this article, https://www.tieonline.com/arti...
From one of the most brilliant minds in education today.
As someone who has to support the code written after it's deployed I would say.
In your comments, explain what the code is *supposed* to do.
I can read the code and tell what it is doing now, but I have no idea if that is what it's supposed to be doing or even if it's working as intended.
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 understand the big picture and the fundamental concepts before using some technology. You need to know what's in there, otherwise you'll reinvent the wheel or follow the wrong direction. This can take hours, or even days, but will save a much bigger amount of time later.
- don't try random things (like guessing method names, guessing what arguments to pass, etc.). Read the API documentation.
- Experiment, compile and test what you did very often. Don't write 500 lines of code before even compiling them. When you have an error, read it, carefully, using your brain. Try making sense of the words in the error. Don't guess. Don't try another random thing to fix the error. Read the documentation again. Make deductions based on observations.
- Format the code religiously, and comment it, while writing it. Reading your own code is what you make the most when programming. If it doesn't have the right structure, you cannot reason about it. If it doesn't have comments, you'll forget what a method does or what arguments represents immediately, lose time rediscovering it, and take bad decisions based on poor understanding of your own code. Commenting code also makes you realize design mistakes
- Use good names. Forget about single-letter variables. Programming is not math. If something is a save button, name it saveButton (or save_button, depending in the standard naming conventions). Not s. Not sb. Again, you'll read the code a lot, and good names is what makes it bearable.
All of this is based on a quite simple competence: reading. Unfortunately, many would-be programmers don't know how to do that.
Pick your problem and don't constrain the language. Let them solve the problem and have seasoned programmers critique their code. The best way to learn is by doing and avoiding piques is a good way to ingrain better patterns.
If you are good at identifying problems or inefficiencies, programming is easy. -Most people really can't, it takes practice.
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. -Most people don't even look or think about it.
Good programmers will identify safety hazards in their everyday life. This translates into fewer bugs due to anticipated user behaviors and more secure code.
If you are good at breaking large tasks into smaller, more manageable ones, programming is easy. -Most people get overwhelmed by large projects.
Good programmer's would make good leaders, provided they had the people skills. Figuring out several ways to split up a task is easy, but determining an efficient separation of tasks based on the resources at hand is more difficult. If you are good at abstract thought, programming is easy. -Most people would rather binge on Netflix than solve a brain teaser.
Good programmer can follow and improve upon a flow chart, identify the underlying concepts and translate them into interconnected algorithms implemented in code.
If you know grammar, programming is easy. -More than (not then) half of people don't know (not no) their (not there) grammar.
A good programmer has to understand the syntax of multiple programming languages, sometimes in a short period of time. If they haven't figured out the syntax of their first language in their whole lifetime, there is no reason to expect that they will ever fully comprehend the syntax of any programming language.
If you can understand the concepts of mathematics, programming is easy. -Most people have no concept of boolean or linear algebra.
Good programmers don't need to be _good_ at basic math. In fact it is a hindrance that causes them to work out results in their head (sometimes wrong) and then put some magic number in the code with no comment on how it was derived. Compilers do this for you and the code is more understandable.
If you are good at making processes more efficient, programming is easy. -Most people are satisfied with the status quo.
Good programmers will program themselves out of a job and move on to a new problem. If a tedious task can be automated, they automate it. If it can be eliminated completely by other means, they do the multiple hours of work that will save the time over the long run.
If you are good at comprehending complex literature, programming is easy. -Most people can't put together their IKEA, much less follow a patent or understand a master's thesis.
Good programmers can read through a complex specification (like an RFC), understand it and translate the algorithms into code.
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 true like if they've been part of a big OSS project, but in general think it's true.
So the first thing I'd take a round on is developing software as a team, both in terms of process and in terms of code. These days I'd probably just skip the check out/check in and go straight to branch/merge and how to develop in your sandbox, when you got something working you make a pull request or push it to the master branch. The code part would be about interfaces and "edge" documentation, that some might study your implementation but most simply want to call your code and know what to expect.
As part of this you should also talk about clear and meaningful naming, how your code should not have unexpected side effects and that your code should not expect everyone to understand how to use it correctly. That it's your job to make sure bad input is rejected properly and doesn't crash the whole system, as that's generally not acceptable in a multi-user system or as a small function in a big program. That goes for other developers calling it wrong, bad data from users, other services or hackers and includes writing test cases with both "normal" input, edge cases and bad input.
Finally you should talk about long term maintenance and running production systems. It goes back to documentation, you got handed down code from your predecessor and you'll be handing down to your successor. Don't expect people will be there to answer questions or explain indefinitely, it can even be you coming back to the same code years later. Requirements change and expand, you need test cases to make sure you didn't break things that used to work. You need to know what code branches are in production and how to patch those in parallel with developing new code.
I think those are the essentials, there's still the issue if the actual code is good or not but it's like trying to lecture someone on how to be a chef. It needs the right amount of cooking and the right amount of seasoning, sometimes you're plain doing it wrong other times you're just overdoing it. Lectures may expand the toolbox but it takes experience to apply the right tool the right way in a given situation. And there's usually more than one solution, some more elegant than others.
Live today, because you never know what tomorrow brings
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.
I'd tell 'em to look at code I wrote five years ago, and then say "Never ever write code this sloppily."
Mr. Hu is not a ninja.
Here are some good practices for developers:
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 number of bugs.
Instead, they should be judged on the ratio of bugs versus the amount of code they produced.
A corollary to the above is that good developers create a minimum of code for a given requirement. More code = more bugs.
Beware of developers who create complex solutions to not-so-complex problems.
3. If your ego is so fragile that you cannot handle making mistakes, you are in the wrong job.
As long as you are creating code, you will always make mistakes.
The key thing is to find techniques/procedures to avoid making the same mistake ever again.
4. Good developers assume something will go wrong in their code and put in more code to handle "unexpected" scenarios.
When something fails, it is really good to have it not fail badly.
5. Test, test and test again. Never assume anything works properly.
I have had code fail several times after many years in production.
It took all that time before the circumstances were sufficient to trigger the obscure bug.
This also ties in with point # 1 above, it is very easy after a few years of success to assume it is bug-free, when it isn't.
6. NEVER stop learning.
You can always improve.
7. With so many opportunities for self-education, learn to choose the most useful ones.
Learning the intricacies of one niche application will cause you to be good at that job, but what happens if that job ends?
A resume of widely-used skills is good for employment longevity.
8. MOST IMPORTANT.
Love what you do. Take pride in your work.
If you don't love what you do, find a new job.
You cannot pay someone to take pride in their work, but you can reward them for doing it.
And which of your workshops was the most successful? I like to join it sometimes, perhaps :D ...
Well, the pimp thing probably not
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
If you had half a year, it would be doubtful you could achieve much. Half a day is a complete joke.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
For the love of trump, just sanitize your input!!!
Be Excellent To Each Other
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 variable thing has a very different source (and you see the same things in engineering and the other sciences) - math has traditionally be done by hand, in steps small enough to make avoiding (and spotting) errors relatively easy. Meaning you'll quite likely be writing slight variations of the previous line thousands of times when solving even relatively simple problems - and mathematicians are lazy.
There's also the fact that unlike code, where you generally want to do as little as possible on each line to improve clarity, a line of mathematics is very often a large and inseparable thing, and a moderately complex line of mathematics can easily span multiple blackboards, even when written with single-letter variable names. Having descriptive names would dramatically balloon that space, deeply obfuscating the overall patterns you're trying to find and untangle.
As for proofs and scientific theories - that completely loses touch with what mathematics fundamentally is. It's a purely theoretical construct designed to sit upon its axioms with utterly logical soundness, using formal logical proofs to construct each new building block from those that came before. Unlike Science, where proof and truth are logical impossibilities, and only successively more accurate approximations are even attempted.
The real world is irrelevant to math - it's a purely logical construct. It's broadly useful in the real world only because those fundamental axioms were chosen to be as simple and obviously true in the real world as possible - most are based in simple concepts such as basic counting and geometry. Formal logic guarantees that *if* those handful of simple axioms are true, then so is all the immense complexity built upon it. The truth of the axioms is well understood to be outside the realm of mathematics, and there are even fields of mathematics built upon adding an axiom or two known to be inconsistent with generally accepted truth (hyperbolic geometry for example), that nonetheless were later proved to be both very useful, and mappable to more generally accepted the axioms (i.e. anything that can be expressed in it can also be expressed in "normal" mathematics, though potentially much more verbosely)
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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
You could take a look at what Software Carpentry https://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.
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-number based inverse square root approximations come to mind)
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Me code pretty some day
A voice in the wilderness
http://world.std.com/~swmcd/st...
https://www.amazon.com/Element...
Dave Barnes 9 breweries within walking distance of my house
Get them to work in a support team before allowing them to develop code from scratch. Having to maintain the mess that is other people's code will soon instil an abject horror of those things that should be avoided.
You never know what is enough unless you know what is more than enough. - Blake
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...
We used their resources and people to put on a series for LANL scientists. That was the initial impetus for this organization back in 1998. They have lessons freely available under the Creative Commons license. I recommend them.
How To Become A Hacker, by Eric S. Raymond http://www.catb.org/esr/faqs/h... There's other stuff by ESR, like The Art of Unix Programming: http://catb.org/~esr/writings/... But essentially, I think you'll find the first web page gives you a good start.
In my humble opinion, the gown-up way to think about a programming problem is to consider how it will perform (scalability, bottlenecks in network/memory/storage/etc), how it will be maintained (who will have to read and understand it, including a realistic understanding that it will look completely unfamiliar to you yourself in a year), where it will have to run (portability), how much time you have to write it, how the discoveries you make along the way will affect your collaborators, whether there will be opportunities to optimize later (and how much effort is appropriate to be prepare the ground for those efforts), etc.
There are trade-offs in balancing all these issues; there's a difference between a quick one-off to assess a problem, versus a tool that may eventually see production use but only accessed by sys-admins, versus an application, versus a proof-of-concept, versus an exploration of constraints on a solution, etc.
Pick the combination of trade-offs that will let you finish in the amount of time that you have, divided by pi, because it's going to take longer than you thought. There will be emails, meetings, surprises, changes of goals, etc.
When you start coding, try to get as quickly as possible to enough of a framework that you can explore the parts of the problem that are most challenging. In other words, answer the biggest questions first.
Try to maintain the attitude that you are a well-intentioned but fallible human who is attempting to solve the problem with the mix of trade-offs selected above, who expects to make some mistakes and is willing to make adjustments to respond to them. Expect that others will also see the problem differently, as they learn along with you about the problems you uncover.
You could do a lot worse than getting them to watch any video (or read any book) by Robert C Martin.
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.
The ideas of "best practices" and "design patterns" lend themselves to cargo cult programming. So let them be aware of best practices and design patterns, but what you should teach is that you should keep refining code until either the deadline runs out, or there's nothing left to remove.
Those who do not learn from commit history are doomed to regress it.
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 start to recognize where things are messed up because... they still are kind of messed up.
How to teach it? Easy, take some part (or a few parts, not to pick on one person) of existing code your team already has and go through formatting and then some refactoring to improve readability (assign better fields, variables, etc.) as it becomes more readable I would hope your team would see and suggest things, and maybe have an end product of the lesson that inspires them to spruce up the rest.
Second, train them to use what you make, if you can get sample input and have the programmers actually try out the end-user processes to input forms, use collection tools, etc., on a sample data, reports, etc., they may realize that they could do some things better to make the system more efficient, and/or the end users job easier, or make the data more useful. Just getting the requirements and the user story doesn't do the same as trying to actually use what you make.
How to train it? You can relate the story of Bill Gates and Satya Nadella trying to install, configure and use Windows 8, I'm sure that was a pretty sobering time for them, happens on all kinds of software..
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
That totally depends on the domain of programming. I am a scientist and program mathematical expression for physics. I don't do Web programming. Hence 99% of what people call programming I do not. I do not use C or any of its derivatives. I follow the School of Niklaus Wirth. "Make it as simple as possible, but not simpler" A. Einstein. A procedure is specified with the word PROCEDURE, not some hard to see syntax ala C. Best practices entail using MODULEs, TYPEs, VARiables, CONSTants. The language I use (Component Pascal) has built in garbage collection so no need for a deallocation routine. It is strongly typed. With C if you can get your code to compile you are only 50% done. With Component Pascal if your code compiles you are 80% done. Text editing and code development are woven together with the BlackBox development environment of Component Pascal. The carat is placed at the character where the error is detected (not just at the start of the line). That makes debugging very efficient. The compiler is very fast so quick error correction can take place and one just walks down through the code making corrections. That whole environment is very different from what most of you experience and consider "best practices".
DGDanforth
Get a copy of a small book called "UML Distilled" by Martin Fowler. Analysis and design are the keys to a successful software project. Read it; live it.
If you want to write good code, do not think like a programmer. Do think like a hacker, and try to imagine how your code could go wrong.
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
Don't blame me, I voted for Kodos
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?
For professional programmers, the most important skill is sniffing out unnecessary work (requirements that will be changed) and putting it off. But if we're talking scientists using code in their work.... 1) Learn to name your variables. No, nobody knows what "d2" is, and knowing it's "delta sub 2" doesn't help much either. Yes, I know your papers are filled with random symbols that are never explained and no one will call you on because they don't want to look stupid, but that's not proper practice in programming, unless you're a Real Programmer. And you're not; the last Real Programmer died at his terminal in early 1999, when he figured out he was going to get the blame for all the Y2K bugs. 2) Subroutines, methods, functions. Yes, you too can use these. Cutting and pasting code and changing variable names instead... not a good idea. 3) Tests. Yeah, you're going to need them. Or you're going to have to retract that paper because your code had a bug and your results were an artifact. 4) Beware loss of precision. Scientific programmers have spent a lot of time thinking about this. You will too. 5) Source code control. Learn to use it.
Even if embedded there are coworkers, project/process people and users. All system interacts with the human world so there are always expectations, written or otherwise. Accept that the value produced by your code is linked to this messiness and try to bridge the gap. Not only do they need your help to solve their problems, they often also need you to help them define their problems (and will often not even like you doing so).
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.
easy walk them through this poster from left to right https://uk.sans.org/security-r...
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 hopefully lead to clean(er) code. Or at least code that can be re-factored later without affecting the rest of the system when they make a mess. Of course, falling into endless layers of abstraction is the opposite problem many CS people have. But if you get good at coming up with data structures and interfaces everything else follows.
2. Understanding the long term effects of their decisions. Hard-coding something might not be a big deal if it's easy to change it later. But some decisions are very difficult to change down the road. Identify them and spend your time accordingly. Consider risk mitigation strategies in these cases, such as prototyping. Experimentation is ok as long as it's done in a low-risk manner (maybe you shouldn't tell them this part). But it's good to try ideas out before committing to them too hard.
3. Try to understand root cause when you run into a programming challenge. I often see what I call a chain reaction of bad decisions. For example, people who don't use IDEs (usually those dirty emacs users) tend to write very large files because managing multiple files is exactly what an IDE is for. Since their files are so large their functions become large because it's difficult to navigate subroutines and helper functions with such a large file. Because of this they end up with a lot of nesting and copy-paste code. Next thing you know they want to change the indentation to 3 or 2 spaces so they have more room with all this nesting.
4. Communicate with your team. Everyone has different ideas on how to do things. If you don't communicate you will end up playing tug of war over competing approaches. Talk and sort it out before you try to force your plan onto everyone else. Approach those conversations with an open mind, LISTEN, and leave your ego at the door.
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.
Test Driven Development is the single skill most worth teaching because: 1) it provides the programmer with an explicit feedback loop that tells them if their code is functionally correct (no matter how poorly the product code is written) 2) it forces the programmer to write the code in a way that it can be used sanely 3) it forces the programmer to decompose the software into small pieces (and decomposing a problem it one of the most important tools in a programmer's toolbox) 4) the tests effectively document the product code 5) the tests give them the freedom to go back and make iterative improvements on the code; iterative improvements both a) facilitate an immediate self-learning process and b) enable the application of improvements learned later on.
1. Where are the logs? 2. When this goes wrong in the real-world, how will you explain what happened, with proof, when you don't have access to the machine it was running on. 3. Before you get to teaching a language make them do everything in pseudo code.
At my last job there was an internal wiki with best practices captured in a handful or so of maturity models (MMs). Much work from senior engineers went into those, and the QA group asked teams periodically to report a consensus on their working level in each the various models, and then those simple metrics (like a number 1-5 per model) were captured on a simple dashboard per team, and made available on the wiki for everyone to see. There wasn't always a lot of management pressure to be at a certain point--reaching goals was the higher priority--but most or everyone wanted to do a good job, and the MMs seemed very helpful.
MMs covered topics like i18n/l10n, testing, continuous deployment & operations, and probably others like design principles and technology choices (like how well they were using web services or something). (There were also clear standards and expectations about language choice etc--so we could move across teams more easily as priorities and projects evolved.)
Each MM topic had a landing page in the wiki, with a table, showing across the top the maturity levels (0=do nothing, 1 might be ad-hoc, ~5=doing it all and optimizing/improving the maturity model's effectiveness/usefulness), and on the x-axis (down the side) were sub-aspects of the general topic, and text in the table describing what it is to be at that level, for that subtopic, and then text on the rest of the page for discussion, instruction on when or why something fits or matters, and references to learn more. Maybe there was (or should be) something about MM maintenance and removing parts that are no longer useful. Of course the wiki should preserve the discussion and history. (There was also a recognition program for developing skills in certain areas, where the topics, levels, and learning resources were written down and somewhat evolving, study groups sometimes formed, something like the maturity models, and evaluators were tech managers or designated staff from across all the teams).
For code quality and reviews, I had started some writing and early discussions to add another MM on that topic. Really my motive was code quality/maintainability, using code reviews as the main mechanism. Level 1 would be ad-hoc but at least something by a teammate before committing to the master branch (I think everyone was already at this level), and other levels would start very simple (to not put someone off who really just doesn't want to think about it right now), including things like using a simple checklist (search the web for the "checklist manifesto"), checking for clarity and maintainability ("would you want to maintain this?"), if code is properly tested, if code comments explain *why* when necessary, if any documentation needs to be kept current, if another team or area needs to be notified about the changes that affect them, standards compliance (ie, with the team's expectations relative to the other maturity models), reviews should be asynchronous (if the reviewer needs you to walk them through the code for the review, how do we know they can understand it when it comes time for maintenance??), doing at least a quick self-review before asking a teammate, ongoing improvement, etc.
I also advocated that every team team should have a wiki page listing the things they maintained or directly related to (ie, when joining a team, what systems do I care about getting up to speed on), and that each project should have a page (from a template you can just copy/paste and fill in or type "n/a", the "10-minute" documentation solution for any system). It included things like: where is the source code, who are the customers, generally what does it depend on, how is build/testing/deployment done, where does it run, what backups are done and who, and a few other things. I just hated having that info only in the minds of the few experts, as it made it seem like depending on individuals and not a well-run team working together. Probably each team should also summarize in the wiki their team-level expectations and practic
A Free, fast personal organizer for touch typists: onemodel
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), testing process (test driven, or whatever), writing good unit tests and writing bad units tests (ie. what not do do).
Shaping self-taught programmers into professional developers is not a one day process. You'll probably also want to implement a peer review system if they're going to be working for you to enforce the standards and sanity checks that you'll want to implement.
Fanatically anti-fanatical
Begin with Gerald M. Weinberg's "Psychology of Computer Programming."
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 - avoid functions with 30 arguments, maybe? Try to identify discrete pieces of functionality and organize your code that way for easy reuse. Break up a few of those 500-line functions, mmkay?
Regression testing and unit testing. How, when, where, and why.
For the love of god, please comment. Also, HOW to comment (document data, document the WHY of your code)
Profiling. Actually measure your shit and understand it before you launch a 1-year-long ground-up rewrite, where you repeat all the same mistakes.
Style guides. The fast and easy way to prevent ocular injury in the workplace.
When I first got started designing websites, it seemed like there were endless possibilities. But everything changes and it's vital to stay afloat with the latest web design trends. Resources like https://studioblackbelt.com/ . This resource offers neat tools and resources available that could seriously speed up the web design process
Mark Twain's essay "Fenimore Cooper's Literary Offenses" saved me from a high school English paper. His opening thesis also turns out to be prescient regarding software design, if one replaces "personages" in a "tale" with the variables or objects in a software system.
... ... ... ... ... ... ...
In addition to these large rules, there are some little ones. These require that the author shall:
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 somewhere.
2. They require that the episodes in a tale shall be necessary parts of the tale, and shall help to develop it.
3. They require that the personages in a tale shall be alive, except in the case of corpses, and that always the reader shall be able to tell the corpses from the others.
4. They require that the personages in a tale, both dead and alive, shall exhibit a sufficient excuse for being there.
6. They require that when the author describes the character of a personage in the tale, the conduct and conversation of that personage shall justify said description.
9. They require that the personages of a tale shall confine themselves to possibilities and let miracles alone; or, if they venture a miracle, the author must so plausibly set it forth as to make it look possible and reasonable.
10. They require that the author shall make the reader feel a deep interest in the personages of his tale and in their fate; and that he shall make the reader love the good people in the tale and hate the bad ones.
11. They require that the characters in a tale shall be so clearly defined that the reader can tell beforehand what each will do in a given emergency.
12. Say what he is proposing to say, not merely come near it.
13. Use the right word, not its second cousin.
14. Eschew surplusage.
15. Not omit necessary details.
16. Avoid slovenliness of form.
17. Use good grammar.
18. Employ a simple and straightforward style.
I encourage perusal of the original: http://twain.lib.virginia.edu/...
"Just because you can does not mean you should...." "Oh, look here: I can make this nuclear power plant fail, going core-melt-down, by deceiving these sensors. Let's see what happens!" Chernobyl, anyone? Fukushima? Only remotely caused, not natural or on-site disasters? "Well, they should have prepared for that. Sucks to be them." But maybe you and your family are "downstream" from the disaster? Somewhere, somehow, some time, some user will enter something that simply never makes sense. "Nobody would EVER do that!" Except they just did. Most likely: they are naive do something the programmer NEVER expected. Perhaps they were just trying to get through the "forms" or "input" or whatever and just chucked "some" value in the input blank to get the job done. More likely, they are malicious, trying to find failure modes using bots, fuzzers, and all those tools, free-for-the-download for the naive and malicious to use. Somebody else said it, but "NEVER underestimate bad taste and human stupidity." (To which, I respectfully add: "laziness and maliciousness". Every time I hoped for a better outcome in the past 40 years, I've been proven oh, So WRONG.) Yes, they will use meta-meta-meta-codes to exploit your program. Reject them and give an error code to whatever called that function, script, or program. Spreadsheets are not databases, although a self-taught "developer" used them as such. (He understood spreadsheets but had never beheld a normalized, rational database. But it showed pretty pictures. I cringed. He built a business on it. Somebody help them all?) Define the job, then find the correct tool(s). Protect those tools from misuse: ALWAYS type check AND range-check your input and use "safe" memory allocation and output functions. "If it doesn't fit, you must reject." from Hard-won experience. I set coding standards for a utility company and input (type / range) checking for a rather large organization, just protecting the little projects I happened to enjoy.
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. Be ready, spend time to be calm, prepared and (above all) practised.
If you're fire-fighting -- and people love to praise a hero -- then get yourselves enough time to reflect and learn from what's going on. Trust your colleagues, because almost nobody shows up to intending do a bad job, to find out and prevent re-occurring mistakes.
It's great that your planning, design, implementation, testing, deployment and monitoring can react in an agile way to changes in your business needs, but doing that with sporadic and ad-hoc meetings is extra strain on your team. Make the meetings routine and clockwork so that it can be low-exertion in contrast to the creative work of documenting the failure modes (in test cases) or designing the interaction, moving parts of the system.
Learn from history:
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 be clear that calculation has about as much to do with math as spelling has to do with literature. It's relevant, but not really the point.
Basically:
Science is a description and depends entirely on experiment - it doesn't matter how beautiful or ugly your description, all that matters is that your experiments match the description within the margin of error of measurements and noise, even in the face of people trying to replicate your experiment to prove you wrong. If you can do that, you should get taken seriously.
Math though is a language for logical manipulation built upon "absolute truth" (declared axioms) and gains *nothing* from experiment - it doesn't matter if you've done a billion experiments (sample calculations) showing that "New Expression" equals "Old Expression" with infinite accuracy - nobody will care. All that matters is whether you have a logically sound proof that "New Expression" is an inevitable logical consequence of "Old Expression", based on nothing but the handful of fundamental axioms of mathematics.
If you've ever taken a math proof-writing class you really come to appreciate how every complex concept must be exhaustively derived from pre-validated laws and theorems - which were themselves exhaustively derived from less complicated laws and theorems, all the way down to the original axioms. It does not attempt to describe anything outside itself, except as expressed in the axioms, and can thus be proven absolutely true within the framework of those axioms.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Declarative code and sensible comments. Unit and integration testing, which helps to refactor and change the code. Refactoring often, reviewing their own code and code of their peers. The code should be understandable to other human beings. It should be well tested so that when changed, the important functionality wouldn't break without notice.
When I was first starting, most of my time was spent keeping code written by the prior developers working. The main affect this has had on my development, is to write to the logs frequently. In particular, I want the log to reflect what it is the code is trying to do, anything about the state of the system that would help, and obviously the details when it fails.
Any woman that uses the word misogynistic loses instant credibility, any man is a mangina.
The opposite of feminism is machismo, no more, no less.
You are an hopeless baizuo.