Use Git Kracken and Other Bad Advice
Photo by Keiron Crasktellanos on Unsplash
Working as a software developer is about learning, developing, and keeping open to new ways of doing things.
So, it might come as a surprise that our favorite software developer The Secret Developer spends much of their time rejecting the suggestions of their colleagues. As usual, our grumpy software developer friend thinks that they are right, and their judgemental behavior is justified by their particular situation.
Let’s hear them introduce this list of rejected advice and see if software developers can learn something about best practices in the article that follows.
“There are so many pieces of advice I’ve received over the years. Some have been great and some have been…less than great.
This is a list of the more stupid pieces of software development advice I’ve received and why I’ve thrown them out as garbage.
Next time you tell me how to do something please think about who you’re speaking to. Thanks.”
Use Git Kraken
A former boss of The Secret Developer recommended the legendary tool Git Kraken to make their life easier. What might The Secret Developer have a problem with?
“I’m working doing some pair coding with my boss. I think it was something pretty trivial like parsing some JSON and they struggled to understand what I was trying to do.
As I pushed a commit from the command line they piped up. ‘Why are you using this. Use Git Kraken so you don’t need to memorize all the commands.’
This might make sense if I didn’t know all of the commands in Git I might need to know. It might make sense if the company would pay for a license. Of course they wouldn’t.
The real reason I like to use tools which are on every machine is just that. I can work on your machine anywhere without any special software. You can’t do that if you’re only familiar with some visualization software.”
Two Heads are Better Than One
Pair programming has been proven to be effective and you’d expect experienced software developers to take that on board and begin to think about adopting this into their practice. Unfortunately, it seems The Secret Developer has a different take.
“I’m working on a feature so why don’t I pull in a junior dev to give a hand they say?
That seems great because I’ll be able to spread my knowledge to other members of the team.
Then the reality hits you. The person you’re working with simply isn’t listening. You use the techniques you have to overcome this little roadblock by putting your colleague into the driver position. They simply don’t do it right. It takes too long.
I need to push a feature out and this wasted time doesn’t make sense. I need to work on my own and think of solutions. I need to be free to do my job.”
Document this
A few comments on some work can make it easier to use those shared classes. What could The Secret Developer disagree with about this uncontroversial statement?
“There is very little that I hate more than comments in code describing what the code does.
You read that right. I don’t have a problem with comments describing why the code does something, I have an issue with comments that just repeat the code in English. I’m sure you’ve been reading this blog for a while and understand that I’m coding in a high-level language. If you’re using C++ maybe take your time with commenting about those pointers or something.
For me, my code is self-documenting and makes sense. I hope that makes sense to you too.”
Follow this trend
When the whole community decides that something is good and the direction for software developers to follow, there is usually a laggard who doesn’t want to follow the herd. I bring you The Secret Developer.
“If I hear someone else saying I need to use TypeScript for my hobby project I think I’m going to scream.
Either that or cry.”
Optimize This
Many teams like to use the most performant solutions. They want to make their code of the best quality it can be. Does The Secret Developer belong to this group?
“That bit of business logic that is only used in one place? I’m not going to make it reusable as it’s only used in one place and will only be used there (until it isn’t). When we need to reuse that piece of code we will extract it and make it reusable and not before.
I understand that you need to optimise your work and make it performant. That particular piece of code isn’t fast but it’s in the background and does not change the user experience. I think if it becomes a problem we should change it.
Can we all agree that I’m right now?”
Conclusion
The conclusion of this article is that The Secret Developer does not take any criticism well.
“I agree partially. I take valid criticism but criticism that makes no sense? No, thank you.”