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.
You don't, you throw random DOS, linux, math, english, and then languages like .net, c++, javascript, java etc all into one giant pot, never explain anything at all, then get mailed a diploma.
*cough* Algonquin College in ottawa ontario canada *cough*
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=-
If you've taught yourself to program at anything more than a trivial level then you're already step ahead of most 1st or 2nd year engineering or computer science students.
Anything you could teach in half a day is less that what would be useful to a generic audience (what's useful to a C++ programmer is not useful to a JavaScript programmer, what's useful for someone writing GL shaders is not useful for someone programming an STM32)
What's the other half day? "How to solve all your personal failings and live happily ever after"?
Really thats all, whats this crap about best practices and all that ivory tower crap.
Learn lisp and c and python, then if you are not thinking like a programmer then , after that you never will. Formal procedures should be specific to your institution and job flow, not some arbitary waterfall or agile shit that just turns people off their jobs and creates a lack of motivation for its best programmers.
Then let them work out best practices for themselves from other people's failures.
Really that is the best and only way to teach, because it requires them to *THINK*, and in thinking come to their own conclusions, then from those conclusions make (hopefully minor in comparison) mistakes, which will allow them to refine further until they make few mistakes, and no critical ones at all.
See for example
Wilson G, Aruliah DA, Brown CT, Chue Hong NP, Davis M, et al. (2014) Best Practices for Scientific Computing. PLoS Biol 12(1): e1001745. doi:10.1371/journal.pbio.1001745 and https://dx.doi.org/10.1002/2015EA000136 . Those are for geoscience, but of course you can find similar papers in your field(s). And then find the papers they cite and who cites them. Your acadmic (university) audience will prefer lessons based on this, with citeable references, than lessons based on Slashdot comments, me thinks.
It's all you need and covers all high level things with 20 years experience
https://youtu.be/JIJZnF_L5KI
https://youtu.be/4H8VTCSbYQg
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'.
Last year I began coding professionally for the first time in my life. I read a few language specific books and then âThe Clean Coderâ(TM) itâ(TM)s available on Amazon and Safari. The chapters on test driven development, automated unit testing, people skills (learning to say no/yes) and professional development outside of working hours were superb and would make ideal topics for such a half day course. That book impacted me greatly and last year my peers at my work awarded me.
Most of my time as a programmer is spent in maintenance, not developing new code. I think most (all?) of our best practices are driven by the need to minimize time spent on maintenance. Unit testing, source code control, issue tracking, OOD, continuous integration, are all driven by maintenance. In order to get someone to "think like a programmer" they need win that hard experience for themselves. Maybe you could set up a running piece of software and give your students a list of bugs and features and tell them to start knocking them out.
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.
Same as with natural language writing, reading is important.
Go read the code and understand the design of a well structured project. And no, an internal tool of a company usually doesn't count. Read something worked on by tens or hundreds of people.
My favourites are the linux kernel and Qt.
Then go read anything that gives you insight into how these people think. (Qt: https://wiki.qt.io/API_Design_Principles)
At the same time, really understand the language you are using.
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?!
Keep the code as simple and maintainable as possible. Slick and too compact code may look good at first, but it makes maintaining and upgrading the code a nightmare.
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?
If you are not targeting any technology/programming language specifically, I think you should focus on what Best Practices means, and it's benefits. Some general examples would be great, but then your students should go and learn the ways of their own tool. Each tool is based on some ideas on how it should be used. What are dose ideas? What where the designers of the tool thinking? How they envision their tool being used? That is, I think, what your students should ask themselves.
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.
A person drawing webpages with the latest ultra-high-level tools and a person writing firmware for a real time transmitter with 4K of RAM and two registries needs different skill sets and "best practises". What is a programmer in the eyes of the OP?
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.
The culture is just wrong for most people and goes directly against software development principes.
* Th Paul Lockhart argument: True math is the skill of solving very abstract problems by finding very abstract patterns/principes.
But the math we learn is merely the memorization of some of those patterns without understanding them and without the ability to come up with new ones. Missing the entire point.
* The 3Blue1Brown argument: Math is unfortunately taught like a written language. But most people do not think of patterns that way. They fail at math, not because they are bad, but because the form of communicating it only serves a small elite (who somehow always act like they want to keep it that way). ... like 3Blue1Brown does so well ... suddenly the most complex topics become natural and easily approachable.
Then they notice that when it is taught in a geometric way
* The programming principles argument: That mathematical language goes directly against principles like using descriptive identifiers, and makes Perl not even hold a cande against how write-only it is.
Generally, mathematicians think that because it is so abstract, they get to not only use useless one-letter identifiers, but preferably ones that you can't even enter on a computer, and that, even if Google would not ignore one-letter things, would be completely ungoogleable. Preferably with them secretly being not just variables, but substituton conventions using multi-parameter higher-order functions in a way way that even finding the structure of the expression by looking at it becomes impossible. (But if you transate it from Snobist to Human, suddenly it is quite easy to read. And if you explain it in a geometric way, it becomes almost obvious!)
I'd say this is deliberate harmful obfuscation for the pure sake of exclusive elite snobbery.
* The scientific method / incompleteness theorem argument: Many mathematicians seem to not bother caring if the thing they do have any relation to reality or usefulness, don't plan on getting there, or even actively reject it. But the problem is: Math is just a set of patterns/hypotheses, that only become scientific theories, once they are actually backed by (statistically reliable) observations from reality, and only become useful, when they allow predicitons in reality!
But instead, many believe that math can stand on its own, and is the best science because it has perfect "proof"! Nevermind that those axioms can never be proven with math themselves, and the true scientific method rejects the concept of absolute "proof" anyway, since the best we can do is statistically reliable patterns in our observations, backed by peers that have also been shown to be ststistically reliable (by us).
Many even suggest that reality is based on math!
I'm sorry, but like religion, thst is literally (nkt even figuratively) the definition of full-on schizophrenia! At that point, they are not scientists anymore, but a cult/religion.
And that poisons the useful math too.
The same problems exists in philosophy, which also shares with math that it predates proper scientific concepts, and is halfway between religion and science.
Because of this bullshit, it took me three decades to find out that I actually love math, and just hate the above madness.
Now I can even get the girliest of "I hate math" girls to see and love the beauty and usefulness of true math. By speaking in human language and using real-world cases that they can actually use.
So: Learn *proper* math. The right way! Yes, I *fully* agree with you there.
"Best practices" Are for cubical code monkeys that bash out generic code. For creative and scientific coding, leave these hindrances out of coding. It is like best practices in painting or music, it stifles creativity. The world is better off with both types of programmers.
I've been working on that for 50 years. 1/2 day might be a bit optimistic.
You didn't say what caused this class. Is there some problem being solved?
Basic project engineering skills are good to review. Why am I making this. What does it have to do. How can this be done. Which path is best. Where can I get each piece. When is the best time to add each piece.
As projects get bigger, respect for complexity is more that useful. Keeping things simple is hard work. Talk about partitioning, interfaces, and abstraction?
Re-inventing the wheel is easy to do with software and dumb. A good reading list for fundamental algorithms and also major open source components might be nice. How major things work like the Internet, or this web browser.
Understanding the consequences of your actions. Order notation is nice for algorithm selection, but having a clue of what is under the hood is also. What is a computer, compiler, interpreter, and the speed differences between something in cache, versus in memory, versus on disk, versus on the network.
Programming languages and tool kits come and go, but there are common concepts that flow from one to the next. Opening this in a 1/2 day lecture is probably hopeless, but at least you could provide some good reading resources.
(You realize that to even offer this in 1/2 day kind of says that the Computer Science isn't?)
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.
Read these three books and summarize them for the developers in the order below. It's not everything they need to know but it's a good start. Most people spent way too much time on syntax and language without thinking about design and architecture. Learning to code in any language is easy. Learning to be a software engineer is hard.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
https://www.amazon.com/gp/aw/d/0137081073/ref=pd_aw_sim_14_2?ie=UTF8&psc=1&refRID=QXDK4PNZSZHE776XZJQ5&dpPl=1&dpID=5154eSTKUxL
https://www.amazon.com/gp/aw/d/0134494164/ref=pd_aw_fbt_14_img_2?ie=UTF8&psc=1&refRID=QXDK4PNZSZHE776XZJQ5
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.
Amazing how many people make a bunch of changes simultaneously. It is hard to understand the impact of individual items when you change multiple items.
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.
Unless you are writing something quick-and-dirty to do a small task one time, take the time to design but also write your code for maintainability. This means writing code with clarity in mind and adding comments for those instances where you are being "clever". If you revisit your code after having not touched it for a year, you won't remember much.
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.
Learn or die. It's the American Way. Recursion is for the weak.
I wrote a book about it, for a very similar purpose as yours, and for good reason: focusing on fixing bugs really seems to clean up programming style faster than anything else.
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
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.
Me code pretty some day
A voice in the wilderness
http://world.std.com/~swmcd/st...
Software Carpentry is an organisation that recognised the lack of software engineering skills in academic computing and seeks to address it. Their most basic workshop containing the bare minimum is two days long.
Rather than going through half a day of bullet points barely touching each one, which wonâ(TM)t sink in or hangs behaviour, focus on one thing. Three things to consider that each could be done in a half-day and any of which would be a major boost:
- The shell and shell scripting (https://swcarpentry.github.io/shell-novice) - academic colleagues who have worked through that have commented on how much itâ(TM)s boosted their productivity
- Version control (e.g. https://swcarpentry.github.io/git-novice) - this is valuable in areas outside of programming too
- Software testing - so at least they might notice when their code starts producing wrong results.
https://www.amazon.com/Element...
Dave Barnes 9 breweries within walking distance of my house
1. Teach them to put *every* piece of code under version control, preferably something like git. I can't tell you how many times having version control came to my rescue in regression analysis and finding where, when, and who introduced a bug into a code set.
2. Teach them how to properly document code, and by properly document code, I mean specifically how to document function prototypes -- what does function foobaz supposedly do; what are the arguments to foobaz supposed to be; what kind of values does it return; does it have default values; are there any edge cases you should watch out for? Documentation doesn't have to be "War and Peace" in length, but it does have to be useful.
3. And to really hammer (figuratively speaking) the point onto their foreheads, introduce them to github.com. Give them the stats on how many projects are hosted on github.com, how many developers, how many languages, how many lines of code, etc.. Point out some of *your* favorite projects hosted on github.com and what the code quality looks like on those projects.
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...
If your code is not tested, it will have bugs. If your code is tested, you have ruled out some bugs.
I hate his style, but love his message. His programming practices are gold.
You can teach anything, but what is needed is a lot of scientific research to determine what the best practices actually are. Current thinking consists of old IT staff exchaning anecdotes from their personal past experience. This lead to a proliferant of influential software engineering methodologies and no one being the wiser if these actually improve programmers' productivity and/or quality.
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.
Review all code they write, bitch about every bad practise they do, but also tell how it should be done. Review also to changes they do when they fix the errors, as at first those will also have mistakes. If you have many people to educate, write a list of common mistakes and answers to them to save your time. At the beginning, expect something like 20 mistakes per review. Always explain what are the benefits of doing something the way you say.
I tested this with about 200 developers. After about a month the amount of mistakes drops dramatically.
Pros:
- It is impossible for them to hide that they don't learn something as you see the mistakes yourself.
- Most common errors in your situation are educated first and most often, making it most efficient educational tool to your scenario.
- Single person can quite easily educate about 200 developers if done as a full time job.
- No risk of wasting time. If someone already knows how to write code, this will have no effect on them.
Cons:
- Rare scenarios might be left uneducated completely. If you want to cover these, you need to give people assignments or similar to see how well they behave in those scenarios.
Write all input processing and file processing as if a hacker was trying to get in. Users WILL do the stupidest things to your program. So put in lots of input verification. Lots of error trapping code (try/catch). Pretend that the user has deleted the file you are in the process of reading it, and trap for it. Got a text file for configuration (XML)? Pretend that the user likes to change an e to an i in random places.
Remember, no program is foolproof as users are ingenious!
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.
I'm of the belief that the best teacher in the world is yourself. I think the more important challenge here is helping them to see that having best practices will make their lives easier. If you succeed at that, there'll be nothing you could do to stop them from learning them.
For the goal of teaching the value of best practices, I'd do code reviews of their own code, talk about stuff that wasn't done right, what best practices would make it better and then have them add a feature to a version of the code that had been cleaned up and that same feature on the original version.
Do a public reading of the pragmatic programmer.
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.
First, teach management why best practices are important and to require them, then worry about programmers. It does not matter who knows about best practices if there is no incentive to use them. Now go finish patching this bug ASAP and push it to prod before you go home ;)
You could do a lot worse than getting them to watch any video (or read any book) by Robert C Martin.
Put them on bug fixes and minor enhancements for a year or two. It is very educational. I learned fast what crappy code looked like. That and to break their spirit ðY
Block Stack Overflow and all other places the programmer can copy and paste from.
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.
Best start is reading Kernighan and Plauger's "Elements of Programming Style".
The rest is a combination of logic, math, and diligence both in programming and dealing with other people.
Understanding that your program should be maintainable if all the people involved in developing it got hit by a bus is key. This gets into development prior to programming but isn't a popular platform any more.
Know what success looks like.
As in, knowing what your program(s) are supposed to do, knowing when they do that and only that.
The rest, well, buzzwords wrapped up in buzzwords.
There's a reason sql injection is still the easiest way to compromise an application.
And buffer overruns.
etc.
Before working on any functionality at all...
- put in a source control tool
- put in a configuration control tool
- decide on a coding standard
- put in place a tool to enforce code review practices
- automate the build
- automate the unit tests runs based on a passed build
- automate the functional tests runs based on passed unit tests
- automate the deploy based on passed tests
- automate the documentation generation
Only then think about writing any functionality.
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.
Often, some trainer with limited real world experience is used. Hire someone that has been in the industry, and has a ridiculous amount of real world experience. Don't be cheap, and realize that your investment in getting the right person for the job will pay dividends.
When to use heap vs stack vs globals vs when to pass things as a parameter
Multiple error handling in functions - nested "if success" vs goto fail, etc
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).
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.
Documenting code is important.
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.
Creating some really complex algorithm requires an understanding of math. However, I would argue the vast amount of work out there deals with business logic and integration so teaching SOLID principles, instrumentation, team work (agile, business), business scenarios, cloud concepts (different way of thinking), tech-debt, code-tone. I know everyone wants to create some really useful tool or algorithm that gets accolades the world over, but it's more likely that you will work on mundane items initially.
Make them do some code, review it and explain things in depth showing consequences, etc. Lots of developers care about best practices but don't understand them. I can't tell you how many times I've looked at code and 90% of it is useless. I ask time and time again why this, why that and the answer is always "best practice". Best practices are dangerous because they can very easily become mandatory practices that you do all the time. Half the people preaching best practices are really just control freaks that want to make you do things you don't have to and that doesn't help.
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.
As a first step it would be useful to have a best practices template to follow. The IEEE Computer Society is the custodian and promoter of the "Software Engineering Body Of Knowledge" which has been created to provide a solid grounding for the "craft" of programming. For programmers and developers NOT to refer to this resource prior to picking up their pencil, stylus or mouse click is to miss out on a very credible resource that can prevent buggy code and misguided solutions. Give it a try...
https://software-carpentry.org/
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
Cover this stuff:
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
https://en.wikipedia.org/wiki/Software_design_pattern
Languages and IDEs have a tremendous number of features you can learn, but for software design it’s more important to know the principles and patterns for software development that masters of the art have originated. Memory and pattern recognition matter more than creativity. OO business software development is about building models of reality using a mental tool bag of design patterns and according to a set of design principles.
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:
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.
1. Make it work, then make it pretty .... or how about we just email the customer a reminder automatically? ... refactor it.
2. Think like a user. Think like a user that will have to use your solution. Think like a user that will have to use your solution 100 times a day.
3. Ask why? Why do you they want this change? What problem is it solving? Users typically bring you their idea of one "solution", i.e. can you add "due date" to this report? Sure I can. but why do you want "due date" on that report? Oh, so I can export it and calculate if a widget is nearly overdue, so I can email the customer to let them know. Uh, ok, we could do all that
4. Don't copy and paste code to reuse it
5. Don't sprinkle hard-coded values throughout your code, replace them with constants
6. Don't build logic into primary keys
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.