Break the Product

Break the Product

Reading Time: ~ 3 minutes

If I start a new job now a days, there is so many things I do differently than the first time I’ve landed my first job. One of them is the fact that I would break the product I am to work with!

Who is this for

Of course if you are the boss you want to see the employee being productive as soon as possible. That is understandable since you have one eye on the well being of the employees, but the other is on the balance sheet’s bottom line. And that one won’t balance itself due to willpower alone.

However, this one goes out to all you newbies out there. Even if you are just starting or you have years of experience but are switching jobs. If you are someone with some influence in the company than maybe see that you facilitate some of the ideas presented here (if you agree).

Be the Product user

Do you want to know what you are doing? I know I am MUCH more effective if I understand the needs of my users. At a minimum I know how the software that I am delivering work.
I can blindly fix bugs based on the bug reports. But I am pretty sure I will have a higher percentage of issues coming back from QA than I would if I understand the ramifications.

Ideally on the initial weeks of your work or on-boarding process of your new project, you would get an introduction to the software you will be working on. You should try some scenarios that were previously though out (checklist anyone?), these can be simple user workflows or even if applicable and possible, a complete environment simulation where you can try everything and receive the appropriate responses from the system or simulated 3rd party.

There is absolutely no harm in trying out different things and thus you shouldn’t be afraid of breaking something. I can say from personal experience: I was always afraid of modifying something and breaking something else I shouldn’t, but I really started learning when I’ve realized that it wasn’t a problem: I wasn’t messing with production code so even if I got the build broken I could always (worst case scenario) revert my commit, which let’s face it: is no big deal. You as a developer should be encouraged to test things in all possible ways, so breaking stuff should be a normal thing. But so should the fixing these things once you find it 😉

Own Time

I was checking my old copy of “The Clean Coder” and saw that Uncle Bob states that knowing the domain of the application you are working on is your responsibility as a professional. Although I agree with this idea, I also do believe that it is not applicable to the tool/product. To illustrate what I mean here is an example:

Suppose you are working for a company that creates software for Dental Offices. Sure it does help to know the kind of activities that it happen on such an office (no need to get a Degree as an orthodontist though). This is usually not possible, so you should get VERY familiar with the software your company produces. To know what works and what can be improved. What happens, at least for the user, when you click a certain button, and other significant details. With this you know the workflows and with that the way the customer uses, or can use, your software.

This simple example illustrate that to know you domain, in this case there is no possibility for you to learn it on your free time. You don’t have the software at home (usually) and most likely you cannot take a copy home.

Returning to the idea on the Clean Coder, I also believe that if you like what you do, and most of us got into programming because we do, you will be interested to know more about what you are working on. So the programmer will have the tendency to study the domain where he or she is working on. But why not speed up the process? If the company offers some courses, time and/or a guided assistance for the employee to learn more about the domain than this employee would also get up to speed quicker. He/She would more productive faster and thus reflecting positively sooner on the bottom line.


So break it! Try everything out and don’t be afraid to screw stuff up. You should be in a safe environment for that. If not, than the company has given you production access to the product. Maybe your first job in the company should be to create a development environment 😉

Leave your opinion, start a discussion, share an experience or just a compliment...

%d bloggers like this: