We who cut mere stones must always be envisioning cathedrals - Quarry worker's creed
I start with the quote, because this is what makes me go on, work hard and unfold something new by the end of each day. This is what this blog is all about, let's just not work let's make something out of it. I am a software developer by profession and it's been almost 2 years that I am writing and compiling codes almost every day. But development is not about just writing a piece of code but also about providing a solution that makes a difference to a product which might be used by millions of people. A slight change in the UI or appearance of the page might increase page visits by thousands of more visitors and last but not the least , its a responsibility to give a product a desired shape and I share this responsibility with my team.
Whatever I will share in this blog is actually a knowledge and guidance provided by a book : "The Pragmatic Programmer" by Andrew Hunt and David Thomas. It has been a true guide which helps in understanding the importance of being a developer.
I recommend this book for all those who want to become a better developer first and then an expert of a programming language, as the book says :
"Programming is a craft. At it''s simplest, it comes down to getting a computer to do what you want it to do".
Take responsibility as a developer : Let's start with the most important and basic aspect of every job that we are supposed to do. It is not just limited to Developers, be it anybody this is the most basic requirement of being an honest and a pragmatic programmer . This is the most crucial part of being a programmer. Despite lot of efforts, hard work, honesty and testing, things can go wrong. Technical problems can show up. But a prgamatic programmer knows that one of the best ways to learn is to accept that it's his/her fault. Despite considering all use cases, few of them were missed out. But what is important here is to get the attitude of figuring out what went wrong, even after taking care of almost all the aspects, what else did you miss? Was it the "change in requirement" or any information that you missed out on? Knowing the reason is as important as to fix it. Find out the reason and make sure next time you consider and remember what you have found.One of the best lessons learned are learned out of self mistakes.
Always be a student(and a self teacher) : The best teacher in this world is you yourself. No one else can teach you better!! This is not hard to realise, it involves few simple steps :
Your knowledge and experience are the most important assets , but unfortunately they are expiring assets. Your knowledge becomes out of date as new techniques, languages and environments are developed. To keep your self updated all the time Invest Regularly . Even if it's just a small amount, the habit itself is as important as the sums.
Diversify : The more different things you know, the more valueable you are. More like the T-shaped skills
Buy low, Sell High : Learning some new technology before it becomes popular can be risky. But the reward can pay-off pretty well. For exampe, learning JAVA when it first came out may have been risky, but it paid off handsomely for the early adopters who are now at the top of that field.
Set some Goals, don't just run blindly . The point is not to just run but to reach to a "checkpoint" which marks some progress and brings in new challenges to reach to the next checkpoint . Follow the guidelines mentioned below :
Learn at least one new language every year : This is where the vertical bar of the T-Shaped model comes in. The part which helps stand a " T " tall. Different languages solve same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut.
Read a technical book each quarter : No matter how popular an "ABC" online tutorial or classes gets. What still holds the importance is the habit of book reading. One who is making the tutorial video might have read a book through which he was able to grasp 75% of what book mentions and when you watched the video you learned 70 % of what he learned. That is a big loss!! I hope this explains enough !!
Read non technical books too : Like the one currently I am refering to. Trust me! this book carries way more knowledge than a technical one. Like I said previously "Programming is an art", dont just think of it as your job.
Participate in local user groups(Communicate and learn) : Show some eagerness to learn something, come out and share your views over the current best technology and what you can contribute and improve. The community is the strongest of all learning mediums. The more you share , the more you get . Stay wired and updated. And always be thankful to the person you learned it from(Remember to share something back).
Stay current : Subscribe to trade magazines and other journals. Choose some that cover technology different from that of your current project.
Estimating : How much time do you think it will take to complete the payment process page?
You must have come across questions like these a lot of time, where you are asked to give an idea about how much time will it take to complete an "ABC" task. At a point they are all "Incomplete" questions(or they are missing information) , but they can all be answered.
By learning to estimate and developing this skill to point where you think about all the use cases that might affect the timeline of the task, you will develop the ability to determine the feasibility of the given task in a specific timeline.
But the most vital part in the statement above , is the "use case/Scenario". Let's pay attention to the question that is being asked here and let's break it down into parts :||| "How much time" ||| "do you think" ||| "it will take to complete" ||| "the payment process" ??We agree the question here is missing a lot of information which you can ask for. But it has enough information to think about the estimate that you can give for this specific task .
These are the steps that you can follow based upon the question asked above to give the most relevant estimate .
Understand what is being asked : The first and the most important part of estimation is to undertsand the objective and the scope of the task. The fun part here is that this can be in 2 different contexts : a) The scope of the task and b) they are asking for a rough estimate. To make it more relavant, you are free to ask questions. Questions related to the assumptions that task might hold, or the conditions on which the output will be based. But you need to make it a habit to think about the scope before starting to guess.
Build a model of the system : The most fun part of estimations is to build a rough mental model of the system. Because while building the mental model you might consider the server involved in the system, or any process that your team follows in a project or you might come up with a rough idea of how it will be implemented. But it is important to think and create a picture of the task that will help your mind to create somthing that will be usefull in long term.
Break the model into components : once you have a mental model ready, try and break into components and see if this can be further broken down into simple calculations making it an easy job to achieve a bigger task. By this you might be able to figure out how these components will interact with each other in the actual implementation. Will this require any third party library or this can be achieved using the core of the technology that you are using. This will help you define the task better.
Keep track of your estimations : As described previously , what is important here is to make a mistake and learn from it. Remember to keep a track of your estimates so that every time you are able to track how close you were.
If your estimate turns out wrong, dont feel demotivated, go back and figure out what went wrong. What information did you miss? May be your model was wrong! Your assumptions might have been irrelevant. Take some time to uncover what happened and make sure you take a note of that.
Choice of IDE : As pragmatic programmers, our base material is knowledge . We gather requirements as knowledge and express that knowldge in our designs and implementations, tests and documents and for all these we need an editor. Our only tool/weapon to showcase our work efficiency. And to be more efficient remember the following while choosing the weapon:
If you are beginner, start with a simple notepad or gedit, do not directly jump on to the fancy, eye catching and colorful logo of the IDE. You must have heard the statement "Great Power comes with great responsibility". But what is imporant first is to get that need for that power. It is important to understand why do we need an editor. And how will an editor help you grow in terms of writing a snippet. But still if you are a beginner , start with the basic gedit/notepad to get the hang of coding each and every statement (inlcuding doc comments).
One editor : " Spend time with your sword, sharpen it, practice new skills and make it a part of your life. " When you choose an editor and start working on it, remember to get deep into it and know that editor well. Use it for all editing tasks such as code, documentation, memos, system administration and so on. Typing " <-- " or a "backspace" ten times to move the cursor left to the beginning of a line isn't as efficient as typing a single key such as " ^A ", Home or " 0 ". The editor will then become the extension to your hand.
Editor features : How to determing whether the editor you are choosing is the best or it has got some competitors in the market ? Here are few simple critirias to judge an editor :
Configurable : All aspects of the editor should be configurable to your preferences. Using only keystrokes is more efficient than mouse or menu-driven commands.
Extensible : An editor shouldn't be obsolete just because a new programming language comes out. It should be able to integrate with whatever compiler environment you are using.
Programmable : You should be able to program an editor to perform complex, multi-step tasks. This can be done using the settings file that it uses to configure/extend the editor based upon the requirements
In addition to these there several other features like : Syntax highlighting, auto-completion, auto-indent, compile, debug and so on The point is to pick a powerful editor and learn it well, cut down the number of keystrokes you need to type, try to expand and use it for more tasks than you already do.As long as you are happy and productive, go for it!
Know Your Terminal : For a pragmatic programmer , the reliable workbench is the the command shell. These are the tools that you need daily to assist your work. One of the best ways to work is to work without much use of GUI's. From the shell, you can launch applications, debuggers, browsers, editors and utilities. But if you do all your work using GUIs, you are missing out on the full capabilities of your environment.Pragmatic Programmers don't just cut code, or develop object models, or write documentation, or automate the build process—we do all of these things. The command line is better suited when you want to quickly combine a couple of commands to perform a query or some other task. The best way to start is to think of all daily operations that can be done through the command line itself. At the start it might be difficult and time consuming than your GUI operation , but once you are habitual of it, you wont feel like using the GUI operation anymore. Writing and executing commands will then be a peice of cake.For windows users : Alternatively, David Korn (of Korn shell fame) has put together a package called uwin. This has the same aims as the Cygwin distribution—it is a Unix development environment under Windows. UWIN comes with a version of the Korn shell. Commercial versions are available from Global Technologies, Ltd.
There are several other aspects of being a "Pragmatic Programmer" like testing your work thoroughly, maintaining a document, writing a decoupled code, code that generates a code and there is lot more that I want to share and talk about. But unfortunately the length of the blog is the restriction. But I conclude by saying that let's make our teams also "Pragmatic". But for that you will have to start by yourself and then establish some ground rules and delegate parts of the project accordingly. The idea of writing this blog was to express and share what I've learned from the book. As the last three lines of the book says :
People should see your name on a piece of code and expect it to be solid, well written, tested, and documented. A really professional job. Written by a real professional. A prgamatic Programmer...