A Professional Craftsman Journey #2

A Professional Craftsman Journey #2

ยท

4 min read

Being a professional programmer is not about delivering fast, but delivering efficiently and cleanly

In basketball, you can be the fastest player in the team, but missing shots will hurt your team, and now your speed not only did it not benefit the team, but it can also hurt them by causing turnovers and waste their time and it will cause the team to lose trust in you and also your manager might keep you on deck

The same thing happens in Software Development, if you finish fast but your work has lots of defects and bugs, it will hurt your company, and definitely cause your team leader to get grumpy with you

Not to mention that you will be more of a liability rather than someone who pushes the company forward.

Long term, you are delivering a working solution, not a scalable solution, which is why people who do that are called High Performant Jerks

This is a term called on people who usually finish things fast, leaving a trail of destruction behind them

Most of those people are coming from freelancing background, where you get a gig, finish it as fast as you can, and disappear, leaving ur clients happy with projects that are finished before the deadline, not knowing that these projects won't scale and they are happy with that

they get paid generously, the customer gets his project as promised and everyone is happy

but in a Startup or Companies environments, those people don't survive long

because in both environment you are required to write software that lives long, software that is clean, tested, well architectured and designed carefully

In the previous post, we ended it with a sentence called...

Do no harm

We harm the functionality of our system when we create bugs. Which is hated by both our customers and our employer, so doing so is unprofessional

But do I say we never create bugs?

No, we are human beings, we can't create anything perfect, but that doesn't mean we are let off the hook.

The human body is too complex, but does that let doctors get away with it when they mess up somebody, so how can we?

When you create bugs, you should be held responsible for them, and take responsibility to fix them and get determined to not let that happen again, this is how you become a professional

So that takes us to the part where QA shouldn't find anything to report...

when you release, you know for certain that your release is Swift, and clean No bugs should be reported back, not by a QA, and certainly not by a user

Like a Samurai katana's cut, it never misses its target, it's a nice and clean cut

krys-amon-eAAR-0iDhic-unsplash.jpg

It is very unprofessional in the extreme to purposely send code that you know is faulty or unsure about it to the QA to tell you what is wrong with it!

But what if we made sure that there are no bugs, wrote tests, and keep writing tests to make sure that our code is well written? we will miss our deadlines this way? right?

Yes and you are correct and this is indeed a valid point, that's why you must always write tests and make sure your code is well tested, you need to test every inch of your code, how do you do so?

By writing your tests first then your implementation.

This is what is called TDD

and you have no excuse not to write tests even in an MVP (Minimal Viable Product) state

Another point for tests is that your test should be automated, Tests that require manual labor will take time, and you should write tests that execute and ensure all functionalities are working fine in a maximum of 5 mins time, and 5 mins is a time justifying more than 2,000+ tests

That's why we write code that is highly testable through highly testable design patterns and architectures

Do no harm to Structure

A true professional knows that delivering functions (features) at the expense of structure is a fool's errand

It is the structure that allows your code to be flexible, if you compromise the structure, you compromise the future of the project

If you want your software to be flexible, you have to flex it!

Most of the Software Developers fear change, they are always fearing that they will break something, why are they afraid? because they have no tests!

Having tests is so important that it turns your fear to passion, that you can change your code anyhow you like it, not fearing that you will break something, it turns you into a sculptor who is just dealing with clay rather than complex 0s and 1s

ย