Bad code exists everywhere. You shouldn't defend it, even if it is your own code.
Bad code exists everywhere. You shouldn't defend it, even if it is your own code.
So you got tired of bad tests and decided it is a good idea to add some fuzz testing tool. Before you do add it in the main branch, you have to discuss it with your team.
Since we are talking about logging, another thing you must do is to be transparent with the user in your user interface.
A lot of things change during development. One day you need a field, another day that field may be completely different. For those cases, use one version to add the new field and another to remove.
If Gerrit is such a mistake, what can you use instead? Git Flow!
When I said "Scala is garbage" or "Gerrit is a mistake", it wasn't "l33th4x0r" who said that; it was Julio Biason. 'Cause I do believe that putting your face to be slapped is the way we grow.
I hate calling software "a mistake", but I can't find any other way to describe Gerrit. You may see people using Gerrit 'cause Google uses it. The thing is: Google misunderstood what Git actually is.
Depending on where you look, "Nothing more permanent than a temporary solution" is either an old Russian proverb or a quote by Milton Friedman. Thing is, temporary solutions, unless you think about the future to fix them, will become permanent.
You may think "Alright, I have a list of things I don't know, but I have no time to learn those things!" You do have time.
You may feel "I'm not start enough to talk about this" or "This must be so stupid I shouldn't talk about it". Don't.
An "hero project" is a project/spec change that you personally think will solve a group of problems in your project. It could be a different architecture, a new framework or even a new language.
Someone that suffers from Hero Syndrome will claim that things won't work unless they are carefully watching over everything.
I've tried to go paperless many, many times. But keeping a notepad and a bunch of post its in my desk has been one of the most helpful tools I ever got.
You may think "This project is so small and so focused on whatever I needed, I should never post it on Github. What would people think?" Github is not for that.
Instead of taking the blows and keep moving, maybe it would be better to your own health to simply quit.
We have two expressions here: "The world turns around"; it means whatever you do, sometime in the future, you'll face the consequences of it. Another expression is "The world of something is an egg"; because the world turns around, if the world is an egg, you'll face the consequences sooner than you think.
Richard Feymann, famous physicist, kept a notebook with the title "Things I Don't Know".
You may think "But I could go to those people and say 'Why are you being toxic?' or 'Why are you attacking me?' or even just tell them it's not nice to say such things. It would help."
I don't believe that's the case.
Microaggressions are defined as "brief, everyday exchanges that send denigrating messages to certain individuals because of their group membership". The hardest part is that they don't sound aggressive.
You'll find people that, even if they don't small talk you, they will bad mouth everything else -- even some other people -- openly.
We get frustrated with code that doesn't compile. We get angry with customers asking things back and forth. We get upset when upper management can't make up its mind. And we lash out on others when that happens.
At some point, you'll describe some solution/decision about some piece of code or some architectural design and people will seem annoyed/pissed about it. When people care about a product/code, they do that.
One way you can learn about yourself is to pay attention on how people react to your actions.
When you're beginning with any language/library/framework, check their CoC; they will protect you from being harassed for not immediately getting what is going on instead of blocking you from telling them what you think.
You are tired of running the same thing over and over again. You kinda remember that something weird may happen, but because you're tired, you tell everyone that "It's finished". Don't.
This is hard. Very very hard. It's the difference between "freedom" and "responsibility".
I've seen a lot of systems that would never run on a isolated computer, like the developer tool, 'cause the system requires running on a specialized environment. Those things are wrong.
Sometimes, you'll have to say no: No, I can't do it; no, it can't be made in this time; no, I don't feel capable of doing this; no, I don't feel comfortable writing this.
Learn when you can't code anymore.
If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies or loses its charms and you'll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.
If it took you more than one hour for you to figure out what went wrong, it is a good idea to put it on list, 'cause these things have the tendency to appear again.
You know what's one of the worst function names ever?
Sleep for how long? It is seconds or milliseconds?
Think how the data you're collecting from your users will be used -- this is more prevalent on these days, where "privacy" is a premium.
One thing a team may decide to fix the continuous flux of code style comments in a code review is to use a code formatting tool to auto-format the code. That's ok, but they should never rely on it.
When doing code reviews, do not focus on style; focus on design things that look a bit weird.
If your project have a defined code style, you must follow it. Sometimes it may not be clear ("this struct/class should be singular or plural"?), but do your best to follow it.
Every freaking time Google comes with their own coding style, it's a garbage fire. The community came with a better style way before and Google seem to come with a style with high contrasting parts just to call it theirs.
Application composition may lead to microservices -- which is good -- but microservices require some ideas about how applications "talk" between them over the wire (protocols and such) which you don't need to start with.
When we were discussing the magical number seven, I mentioned that it made more sense to actually call the functions in sequence instead of each calling the next. That's basically a "function composition", one thing you can also do with your applications.
In this day and age, when everything has a graphical interface, does it still makes sense to add command line options to your application? In fact, it does.
Do not ignore the power of configuration files.
One thing you must learn is how to break your project into smaller libraries, to avoid doing rounds to deal with "the same, but a bit different".
On a previous life, to understand how a system behaved, I added a ton of metrics: how fast things were going in, how fast things were going out, how many things were in the middle, how many the job processed... Not doing it so makes me feel... naked.
Let say you need more performance on your application. You may be tempted to look at your code and think "How can I keep this same logic and still remove a few cycles, so things seem to go faster?" Well, if you want performance, you need to change your logic.
A lot of projects assume that you'll put things with the same functionality in the same place, no matter what data they deal with. This makes things harder to break apart later.
When working with source control tools, keep one change per commit. Avoid bundling more than one change in a single commit just to "save time".
"This is my stupid application that I just want to learn something" is not even a good excuse to not use a version control system.
I heard a lot of people complaining that code editors are bad 'cause it's hard to attach a debugger. I'd claim that this vision is wrong.
A lot of languages/libraries/frameworks add a way to make things shorter, reducing the number of things you need to type.
But, later, that will bite you and you'll have to remove the shortcut and do the long things.
Two things in one: First of all, when using logging, use it to log events, not for user interfaces; second, log events in a machine readable way, not necessarily an human readable format.
Sure that IDE will help you with a ton of autocomplete stuff and let you easily build your project, but do you understand what's going on?
One way to get away from the IDE is to "start stupid": Just get the compiler and get an editor (ANY editor) with code highlight and do your thing: Code, build it, run it.
No matter if the date you're receiving is in your local timezone and you'll display it in your timezone, sooner or later, the fact that you ignored there was a timezone behind that date will hurt you.
Long gone are the days where ASCII was enough for everyone. Long gone are the days where you can deal with strings with no "weird" or "funny" characters.
"Cognitive dissonance" is a fancy way of saying "I need to remember two (or more) different and contradicting things at the same time to understand this." Keeping those different things in your head creates a cost and it keeps accumulating the more indirect the things are ('cause you'll have to keep all those in your head).
When you're trying to find a solution to your problem, think on the way the data will flow through your code.
At this point, you should at least have heard about how cool functional programming is. There are a lot of concepts here, but at least the very basic ones you should keep in mind.
"The magical number" is a psychology article about the number of things one can keep in their mind at the same time.
"Cargo cult" is a type of cult which appeared in the Melanesia, in which the natives would build their copy of an airplane (no motor, 'cause they didn't have the knowledge to build one -- or even knew what went inside the airplane) in the hopes they would get the same results as a real airplane.
Simple rule: Is the code yours or from your team? Good, you can make any changes you want. Does it come from outside? DON'T. TOUCH. IT.
Most of the times I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern.
A lot of times I heard "We should use the right tool for the job!" Most of those times it was just a way to push an agenda.
Maybe you're in a project that needs to process some text. Maybe you're tempted to say "Let's use Perl" 'cause you know that Perl is very strong in processing text.
But that may still be not the right tool.
You may be tempted to use a list (or tuple, if your language allows) to keep your data if it has, say, only 2 fields. Don't.
Although that sounds weird, it's better to not add any error handling than silently capturing errors and doing nothing.
Memory is just a sequence of bytes; bytes are just numbers from 0 to 255; what those numbers mean is described on the language type system.
If you know an error can occur, then you should handle it properly, instead of ignoring it.
Picking a programming language is much more than just picking the words that will generate a code. They come with a community, a leadership, an ecosystem and a thread the binds them all together.
When you're designing a function, you may be tempted to add a flag (a parameter in a function that it is a boolean). Don't do this.
Functions should do one thing and one thing only. I clear indication that you're breaking this principle is the need to add an "and" in its documentation.
Interfaces and APIs is what you give away to others. If you keep changing them, you'll make everyone's life sad.
If you're worried about learning some new programming language, you can bet the one with a better documentation is the one that is born with a document processor.
Same goes for the frameworks/libraries of that language.
When you start the code by writing the general flow as steps and making each step a function, you're actually making a contract (probably with your future self): I'm saying this function does this and this is what it does.
We all know writing the damn docs for functions and classes and modules is a pain in the backside. But realizing what you were thinking when you wrote the function will save your butt in the future.
When developers try to solve a problem, they sometimes try to find a way that will solve all the problems, including the ones that may appear in the future.
If you write a test for every single function on your system, and your system keeps changing, how will you know when a function is not necessary anymore?
You can be sure that if a language brings a testing framework -- even minimal -- in its standard library, the ecosystem around it will have better tests than a language that doesn't carry a testing framework, no matter how good the external testing frameworks for the language are.
There is one magical thing you need to know when reading this book: It's all personal opinion
Gherkin is file format for writing behaviour tests (BDD). But it can also give you some insights on what you should do.
The view of the whole is greater than the sum of its parts. And that includes tests for the whole compared to tests of single things.
Testing things in isolation may give a better view of your APIs.
You know that "Play" with a little something on your IDE that runs only the tests? Do you know what it does?
A lot of people, when they start with TDD, get annoyed when you say that you may have to rewrite a lot of stuff, including whatever your already wrote.
"Things I Learnt The Hard Way (In 30 Years of Software Development)" started as a simple sequence of toots (the same as "tweets", on Mastodon when I was thinking about a new presentation I could do.
But why "a new presentation"?
"Without requirements or design, programming is the art of adding bugs to an empty text file." -- Louis Srygley
Don't know how to solve your problem? Write the steps as comments in your code.