Listen boy, this is good information from a man who’s been making mistakes.
Billy Joel. Tell her about it.
Well, I guess Hello World. I am approaching nearly two decades of computer usage and one can classify me as the perfect Internet consumer (or lurker, to make it more savage) and the cheapest Internet contributor. So yeah, I feel like I am opening the door to my shelter, from which I have been hiding and waiting for the radiation to dissipate on the surface.
Maybe I refrained from getting out from the underworld and getting help from the World because I am an impatient man. I strive for questions to be answered right now. Posting on forums and waiting three days for the answer is not my cup of tea. Anyhow, here I am, the third ranter on this blog, the founder of Majisti inc. now sprouting to action, entering the fray, ready to share some of my modest experience, knowledge and most importantly, my crazy thought process.
Practicability at the Expense of Giving Up on Your Carelessness
So hmm, the pragmatic programmer! How did I become one? It is certainly not a gift given at birth. It is certainly not my rigorousness at school nor in my personal life that pushed me. An agenda was something that I used to form my little book pyramids on my desk, a larger book at the bottom, agenda on top, and that was it. Well, that was before it ended in the back of the closet. I was the guy asking for loose sheets from the person in front of me, to his daily annoyance. I had average marks and was content with the 20% effort for an 80% result.
Fast-forward to today and I am this programmer who keeps a super tight personal and professional agenda, tests all his code and strives for 100% code coverage and lies to himself that having around 80% coverage should be good enough. I am this person who values craftsmanship, not because the end is a result of beauty, but an investment for my future. I want to accept responsibility for my work, want to enjoy changing my code and act with professionalism. I listen to my inner feelings when I get the tingling sensation that I am doing the same mistakes from the past. I value the depth of what I learnt in the past and I constantly look for ways to perform and apply that to the issues at hand.
I became an investor. I invest my time by constantly learning new techniques, tools and methods. I came to understand that I am someone who cares and is passionate about what he does. Investments become profitable in the long term; you then cash in the interests. Writing code that is maintainable and reusable is being the capitalist programmer. You want to cash in later on. You save time debugging and adding new functionality. You keep having fun crafting and you complete your projects without trashing them at the end. You can maintain projects and keep your promise of solving problems for your clients without emptying their pockets as the project grows, now that they need you with continuous development. You then gain a good reputation. I came to understand that taking the issue at hand upfront and listening to what people have to say will grant you independent expertise that is highly resellable. Information that people pay for because they failed to listen when the information was freely given without them asking.
I am this person who values craftsmanship, not because the end is a result of beauty, but an investment for my future.
From what was said above, we can identify the key points to success needed:
Take responsibility
Be professional
Listen
Invest
Care
Be passionate
Value your reputation
Keeping Pragmatism Balance is Well… Practical
It is great to have ideas, but you have to keep a balance on how many ideas you execute… and you should execute some! It’s by forging that you become a blacksmith. If you keep jumbling and fiddling with your ideas, you will need to find a technocrat; but the sheer act of finding someone to do the job is also being practical. It’s all about being proactive. All that matters is that you start implementing your ideas.
Now, you might find that you have limited time in life. You might be the type of person who wants to spend time with the people he loves. Developing consumes time. Worse, having a short-term vision over your long-term projects will cost you more time. Working one-month full time correcting bugs on a new application that was released in production is nor time nor cost-effective. You suddenly find yourself working overtime to continue pouring in features and fixing those bugs, at the cost of your time. I tell you, working overtime is a sign of bad management. You must therefore find a way to become effective. Wasting time is not practical. Careful planning and proceeding with logic to have the proper balance with your hobbies, family and work quality is the pragmatic thinking that you slowly start to adopt.
Some will misinterpret me. Being efficient does not mean taking a code kata systematically every morning. Being pragmatic is being able to recognize where your time would be better invested. Investing in 1 week to save 5 seconds is not practical. You get pragmatic when you become aware that there are things that slow you down daily and that investing your time will give you a time profit.
How to Become a Code Capitalist
I value core principles to produce quality code that will be maintainable and thus save me time across my career. Some of those subjects will be tackled in depth in future posts. To sum up the list:
Test Driven Development / Behavior Driven Development (TDD/BDD)
- Stay tuned for future posts on that one, as I have come to go deep into this subject. This practice is the pillar of code quality. Without it, one cannot achieve code clean enough without wasting time
Clean coding techniques
- Some of you might be familiar with the books Clean Code and The Clean Coder by Robert C. Martin a.k.a Uncle Bob. Practicing TDD will get you there; you will no longer need to explain what your code does because it will become as readable as a children’s book.
The S.O.L.I.D. and G.R.A.S.P. principles, along with software patterns
- Now when you do TDD, you find yourself coming back to the drawing board more often than not. It is because you are striving to make the current code testable. To fasten the process of assigning responsibility to your objects, these principles will help you iterate on your design.
Continuous integration
- We need to constantly validate that what we ship is production grade. Tools like Jenkins will not only help automate your tasks but will serve as the hangman that punishes those who have broken the jail.. err builds.
Time-boxed iterations
We all know how Agile and Scrum work, but we all have difficulty working in those frameworks. Those frameworks are implicitly pragmatic, they force you to constantly retrospect yourself as a team to become more effective in all aspects of our domain. Usually, a decline in practicing those will be the start of the decline of all other subjects we have just enumerated.
Personal coding and hack and slashing
- To keep that passion, you need to reward yourself with some fun to do projects. Doing this in an environment where there is no pressure will be more productive than you think and probably serve you more for your career than you thought.
Distribution estimates
- No matter if we estimate with story points, management will always want to have costs. Costs get easier to estimate the further you are within the project. Therefore, the younger the project is, the more often must you estimate with distribution statistics. Distributing your estimation will help you keep your engagement with others.
Those principles apply very well to OOP. It might differ for procedural code, but I think the essence is the same no matter if you program something on a raspberry pi or for the Web.
The funny thing, when you think you are alone in your crazy thought process, there is usually someone who thinks alike. I stumbled on the book The Pragmatic Programmer by Andrew Hunt which is yet another worth reading book.
I would say though that there is a book that struck me even more than this. The Code Cleaner, again by Uncle Bob. It explains so well how to become a true professional and although the ideas in the book might seem a bit extremist, applying some of this advice greatly changes the game. I would say that to understand those books, you need to have gone to war. Past experiences that have been more unsuccessful than positive will give you the drive to make things better in your next endeavour. In my mind, those books forge you to pragmatism.
“Meeeh, I Ain’t Got Time For This”
The thing is, people think that proceeding with principles that encourage quality is a waste of time because they are on a tight schedule. My advice is to take a retrospective shot at what you are currently working on. I bet a large percentage of your current time is dedicated to fixing the technical debt that you have accumulated over time. That is a result of failing to understand that time invested now is time saved later. Why can we so easily calculate that 100$ today is not 100$ in 2 years, but fail to apply that same technique to things we program? The answer is simple: we need to start taking responsibility and acting as true professionals.
I think us, developers, fail to invest in quality because in most cases, people are not dying behind our decision
You do not have time today because you did not invest before, just the same as people having no money saved, expend it all without putting some aside, and now they do not have enough money because they are paying their debt. You have probably said yes to cutting corners when in the end, people were relying on your expertise for a schedule. Worse still, technical debt works the same way as traditional debt. Pay only the interest and you will forever have capital to reimburse. A professional has limited time to invest and therefore he takes a pragmatic approach.
This might be radical, but I think we, developers, fail to invest in quality because in most cases, people are not dying behind our decision. If users were dying out of bugs that we create, it would be unethical to have an approach that does not care about reducing bugs within our software. Since we are not always programming software for aircraft, we should slightly change our consequences. Rather than having people that die, we could imagine ourselves being the investor in what we program. Would you sell yourself a 2 months bug fixing session at 90$/h per developer, knowing full well that only the accumulated debt would be paid? I don’t and therefore I act. Some people will argue that big corporations have the money to pay that debt, but the problem is that they cultivated a mentality based on the fact that they have enough money to clear the debt. The truth here is even corporations are not willing to spend the budget on killing technical debt and the customers just end up paying for it. I do not agree with that approach.
I would rather resell at market value stuff that I enjoyed creating, that cost me and my customers less, took me less time to develop and that opens me to future opportunities that I could not calculate when I started the project. I keep this approach even if the end up delegating the project to my employees and not doing it myself.
For all this, pragmatism is one of the core values of my team and the reason for this is we have seen what a bad investment ends up costing in time and money.
