This is somewhere for me to rant about software development on the internet. I'm not necessarily good at always following my own advice, but what I say here is what I aspire to.
Must watch video by Ben Awad: Software Engineering "Best Practices".
Ben worded this really well, in my opinion:
"The problem is, best practices are not universally useful. They are good in a specific situations, but if you take them out and you use them in a wrong scenario, they are just much worse." ... "One of the reasons I think people want to earnestly follow best practices is because they want to avoid writing bad code, which is a good intention, but I think it backfires on you."
And every developer needs to have this tattooed on them:
"One of the universal laws of of programming states that writing bad code is a pre-requisite to writing good code. You need to stop trying to skip steps."
The clue for us is that there are often multiple conflicting "best practices", and that over time, the same people that say to do X are now saying to NOT do X, but to do Y instead. Clearly it wasn't the best. Just the best, in their opinion, for their scenario, at that time, only because they didn't come up with something better yet.
I will say that if you have no place to start and no experience solving some particular problem in some specific scenario, starting with someone else's best practice is the obvious correct place to start. Absolutely do that. But don't stop there. After you've done the work, evaluate the code. What about it worked well and what did not? Iteratively improve the code until it's your own "best practice". The more you do this the easier it will become.
No one writes good code on the first try. Of course we all think our code is great until we look at it retrospectively. Write it the first time as best you can, but don't commit it until you've gone over it multiple times. Don't be afraid to completely re-do parts or even all of it. Your manager will be upset at how slow you are, but then will start wondering why your code has so many fewer bugs than everyone elses, and why everyone wants to work on your part of the codebase and not all the other legacy stuff no one wants to touch.
Business folks think they know what SDLC is. They can draw you a graphical representation and explain each of the steps. But they won't actually follow it. They'll say all the right words like "agile", "iteration", "mvp", etc. But they have no idea how to actually do it. They'll sometimes completely skip the evaluation phase. They'll skip the improvement of existing features. Once you release the MVP, it will instead become the finished product in some people's minds. They'll then be upset if you need to spend any more time or money on it. They don't realize that the SDLC and agile diagrams are circles and are meant to be repeated on the same things, iteratively adding onto a feature and improving it. They see something shiny in a UI and to them it's done. How wrong they are.
However, I'm not sure it's really their fault. They aren't software engineers. They've never written a single line of code. Middle management has pressure from those above to make the numbers look good, and they think what we as software engineers are producing is a one-time thing. For example, they may consider the creation of a feature as if we're painting a picture, and then it's painted and done, and then you move on to another unrelated painting. They sometimes don't consider that despite all efforts to de-couple systems, much of what we do is built on top of everything else we did, and that most successes and mistakes compound over time.
Can we fix this disconnect between the business people and the technology people? Probably not directly. But we can sure try. We don't have to be rude or negative about it. We just have to continually say the right things and ask the right questions. Never assume they know. If we don't say it, it won't be said. For example:
- Have you planned for the feature's post-release inevitable feature tweaks and possible bug fixes?
- What is the budget for long-term maintenance of this feature once it's complete?
- The shortcuts you forced us to take to get the feature out the door will cause severe issues if we don't address them in 6 to 9 months. Which resources have you scheduled to address those and when will that work start?
- Have you scheduled resources to work on the tech debt on the feature so that future features that add on to this aren't fragile?
- Are you willing to take the long term hit for this short term decision? It's a valid strategy if the numbers make sense, but it needs to be qualified.
We use words to communicate, but sometimes we end up with words or phrases that mean something completely different for different people, and that makes communication hard.
Have you ever heard someone say these phrases?
- "Don't over engineer it, we don't have time"
- "I can't read or modify this code, it's too over engineered"
- "That feature is over engineered - it didn't need to do X or Y"
All three of these have different meanings and are all wrong, in my opinion. These are all problems that need to be addressed, but to me using the phrase "over engineered" negatively makes it sound like you don't want people to write good code. Bad move.
What the phrase should maybe have meant is something more along the lines of:
- "Don't add functionality onto your feature that wasn't asked for and there's no predicted future need for"
- OR maybe in a situation where you're trying to communicate that additional effort has diminishing returns and to draw the line before added value for additional effort goes below some threshold
In some rare cases someone might be critisized for "over engineering" something where they spent too much time polishing something. They may very well have spent too much time on something, but we should not be critisizing them, we should be patting them on the back and giving them a bonus and telling all the other developers to be like that person. Critisizing a developer for trying to produce good code has a significant cost in the long term because they are now properly demotivated from spending the additional sometimes necessary time to make code good. If it becomes a real problem for a developer, work with them to find the right balance. But in my opinion, this is an incredibly good problem to have - developers that try really hard and care a lot.
If it's actually one of the other problems, maybe use a different phrase and not "over engineered". That's just kind of offensive and demotivating, in my opinion.
A pet peave of mine is when people frequently state their opinions as facts, and not only facts, but facts that cover all possible scenarios and are absolute. Something like "we should always do X because <some respected person> said so". I'm painfully aware of this because I fall into this trap frequently and sometimes need to be slapped in the face to make me realize what I did.
The answer is usually "it depends", but ... it depends.
Is microservices the answer? It depends.
Is monolith the answer? It depends.
Is monorepo the answer? It depends.
Are those the only options? Only if we have no imagination.
I get stuck on existing ideas and am sometimes unwilling to venture into the dark. I'm afraid of failure. But there's some really good ideas out there in the dark along with all the bad ones. We should be creative and try stuff. Be willing to fail. Maybe <some really awesome project you think is going to change the world> is the dumbest thing ever. I won't know until I try it. While creating it I'll radically change my approach several times before I find something I think might work. It might completely change again later. I may still not be sure whether it will be a good pattern at all, but I'm going to keep experimenting.
Maybe don't be so creative at work though. If software development is your passion, do it in your own time as well as at work. Do your experiments at home and bring the best ideas back to work with you. But please don't experiment on the rest of us. See the section titled "The Bleeding Edge and the Herd".
Change your mind. It's ok, really. Learn and adapt.
All developers should be on the bleeding edge of new tech. This is our craft and we should be deeply invested in knowing what new tech is coming down the pipe and how we might be able to take advantage of it.
That being said, this should happen in our personal time. If you work somewhere that specifically wants to be on the bleeding edge with new tech for one reason or another - you're one of the lucky ones. For the rest of us, it's imperative for us to stay with the herd as much as possible.
What is the herd? If you're at the front of the herd, you're going to be the first one off the cliff. If you're the last in the herd, you're going to get picked off by some predator. I don't feel like mapping that to real world developer experience is necessary - I think it's pretty obvious.
I think this is subjective and maybe a little controversial. I could state my opinions about how to interpret github stars or the stackoverflow survey results and other sources, but that's not really the point I want to get across.
My main point here is that we should at least take into consideration whether we're staying with the herd or not and try to avoid the most obvious non-herd tech. And not just for bleeding edge stuff, but also for older tech. If someone told me we should re-write a modern C# .NET core app in Ruby, I would raise my eyebrows. If someone said we should re-write that same app in some brand new javascript framework that just came out last week, I would die a little inside.
If you think Ruby or Haskell is cool (sorry Ruby and Haskell folks, don't take it personally), do some personal projects first and bring to the table some hard facts and examples of reasons why your company should use those instead of what they currently already know and use every day. If you think it's cool, that's great, but it may be a really bad choice for your company right at the moment.
Should I chose a statically typed language or a dynamically typed language? It depends.
The obvious answer is that it doesn't matter and that you can be successful with either. While that statement is not technically wrong at all, I think it lacks precision and deserves a better discussion.
Whenever a javascript or python developer complains that you have to write a lot of extra code in java and c#, I just roll my eyes.
First of all, it's a trade off. I get compilation checks and all sorts of cool IDE features and faster production performance. In exchange for those, there are more characters in my code. Quite a few more, in fact.
Second of all, I'm not actually typing all that, I'm not using notepad. VSCode, IntelliJ, Visual Studio, Rider, WebStore, etc all do most of the typing for me with the intellisense and auto-complete that you poor python developers could only dream of (PyCharm does amazing despite the language but even that leaves a lot to be desired compared to a statically typed language).
Third of all, having to write all that extra code prevents developers from shooting themselves in the foot. You can prevent your python from shooting you in the foot, but guess what, you're going to have to write a bunch of extra code to mitigate that, and even then, your IDE isn't going to tell you, it's going to be a matter of writing a crazy number of unit tests, and even then you still won't be totally protected from runtime bugs that an IDE and a statically typed language could have caught for you.
Forth of all (sounds like "first of all" with a lisp), it really depends on how many programmers on on the project, what libraries you need and what the size of the project is. If you're writing a simple small script, it makes a lot of sense to have a python or shell script or javascript script instead of a heavy weight compiled application. If it's a prototype that will never actually be deployed to production, great - use whatever is fastest for you.
For real-world production web applications with a large codebase and many developers, I would probably never recommend using a dynamically typed language unless there was an incredibly unusual hard dependency on some particular library or framework that was needed. The only exception would be javascript, but only if you wrapped it in typescript. For your small projects with only a couple of developers or small scripts or prototypes, use whatever language floats your boat. But for everything else, let's use the best tools available.
There are of course some exception for things like data analytics. For example Python and Jupyter is a really interesting concept that would be more difficult (but not impossible) to implement using some other tech. As with most things - it depends.
Software development is hard and we all have a different amount of mental horsepower and life/career experience available to us. As a result, it's common for people become frustrated with one another. As long as we're all trying our best and trying to continually improve, we should all be patient with each other.
We tend to want to spend brain cycles figuring out who's fault something was, but that isn't super helpful, unless it's to try and level up whoever made the mistake and assure them that we've got their back for next time.
Give credit to people. Even for small things. If you're in a meeting and someone soft spoken comes up with the solution everyone's been looking for, and then you point out who's idea it was, you're going to be rewarded with more great solutions and ideas from that person and others like them.
I've worked with people that just agree with everything said and say whatever it is they think the listener wants to hear. While that seems pleasant, I'd much rather work with someone who disagrees with me and points out flaws in my thinking or suggests better ideas.
Disagree frequently, but be nice about it make it constructive. Be precise and defend your opinions. Be willing to change your mind.