– Source orbitvisual.com
]]>When I am interviewing a candidate for a job, I always ask this question: “Tell me about the tools you have built or improved to make you more effective at your job.” Craftsman’s eyes light up, he sits straight with an improved posture, leans forward and starts talking about the tool(s) he developed and how it made a difference in the way he and his team accomplished their daily tasks. He forgets that he is answering an interview question, because now we are in his teritory which he knows like the back of his hand and he is most proud of having built. All I need to do now is find out how well he did what he loves doing most.
I need at least one craftsman on my team who helps sharpen the metaphorical saw while others saw away at the trees.
]]>Just being able to post a few words on my blog feels great.
]]>There is more to this book than just [literary] writing. Surprisingly, the insights gained from reading the first chapter go beyond the craft of writing – to software development, i.e. writing code. Following are a few assertions that the author makes which apply to writing code as well.
I am happy to be reading this book.
]]>Most ideas die without seeing any effort dedicated to preserving or implementing them. My guess is that ideas die mostly because they are never captured. An idea surfaces as a spark in someones head only to vanish in the next moment because that person got busy with something else.
One common practice successful people say they use to take ideas to implementation is by capturing the idea in the form of a note before they forget the details. They usually do this by always carrying with them a notebook where they can jot down the idea as soon as it occurs to them. Its important to do that right away because in that moment of inspiration, you can get into as much detail as you want about an idea and start taking notes before you forget or lose interest. Its like listening to your brain develop the idea while you quickly take notes before the brain decides to shift its attention to something else. Scott Adams says that you know you have a good idea when you feel a physical sensation in your belly when the idea strikes you. When that happens, grab your notebook and a pencil, and write it down.
The point is, make a note of good ideas and with as much detail as possible. Doing so will greatly improve the chances of that idea being implemented.
]]>In the post, he makes an interesting observation about feature backlog:
]]>Every product attracts new feature ideas, and you can’t implement ideas as fast as you can think them up, so you write them down, and this list is called the feature backlog. A lot of the ideas on the backlog are bad ideas, and you merely wrote them down to avoid hurting the feelings of the people who thought them up. Backlogs make everyone feel good.
]]>So you will take risks, and you will have failures. But it’s what happens afterward that is defining. A failure often does not have to be a failure at all. However, you have to be ready for it—will you admit when things go wrong? Will you take steps to set them right?—because the difference between triumph and defeat, you’ll find, isn’t about willingness to take risks. It’s about mastery of rescue.
I dont know what to make of the last two, but I have been type 1 until recently, and am trying to move to type 2. Let me explain…
When you remember yourself from the past that you like better than your current self, and if you think those days were better than today, then you probably like others to see you the way you looked in those days. That’s type 1.
But if you are happy with yourself today, and that is how you want to project yourself to others, you will tend to put up a recent picture of yourself. That’s type 2.
Up until now, my profile picture used to be from 2004, when I used to be at the peak of my physical fitness (no, not the 6-pack kind – just less fatter than today). That was the self that I always wanted others to see me as. But I have come to a realization that hanging on to the past will not make my present any better, leave alone the future. I like to think that my tomorrow will be better than today. So I recently changed my profile picture to one that was taken recently. This picture is almost like a mirror in front of me, reminding me of what I look like today. And if that image does not match the image that I want to see, I better do something about it now. Be regular at my daily excercise perhaps. It is almost like looking in the mirror.
]]>Now, we don’t pay attention to saving frequently because:
Recently, for some reason, I turned off the backup file in my Vim editor and realized how misguided that step was when I lost just 10 minutes of work due to a power failure (remember, my laptop battery cannot hold even for a second). Every single minute I spent reproducing the lost text, I kept saving the text while cursing to myself about what had just happened.
Of course, the solution is simple. Next week, I will find a replacement for the battery and just to be safe, have turned on the backup files in my Vim configuration. I hope to forget about having to repeatedly save files once again.
]]>Administrators want to easily …
Policy deciders want to …
Users want …
Other developers want …
This is taken entirely from the slides from the talk Christian Hammond & David Trowbridge gave about ReviewBoard in 2008. This talk can be viewed on YouTube here but I did not find the slides anywhere else and hence wanted to capture this in writing in a blog post.
]]>I was never asked this before, therefore a prepared answer was not available. I remember asking him what that meant. Was this a trick question? After being told that the question meant exactly what it said, i.e. he wanted to know if I had a story to tell about my life – a story that captured the essence of what the journey has been so far, what have been my influences so far, what and who am I motivated by, what events changed the course of my journey, and most importantly, what am I headed towards. That last part is as important as all the other parts put together. That one thing will say a lot about what I care about and why am I doing what I am doing, and what guides my actions.
This is powerful stuff and I have thought about this question a lot since. Now I do not make a major decision in life without invoking this question and thinking about how this decision will shape the answer to that question. It has also influenced my day-to-day actions – sort of helping me answer the question: what do you wake up for?
If I am ever asked this question again, I have an answer this time. Maybe a long answer, but an answer nonetheless. And that colleague of mine is part of the answer.
]]>Ok, so why does this matter? In a small to mid sized team, say up 20 people, new engineers do not join your every other week. So why solve the problem of having a new engineer commit code on day one? The answer is: to make this happen, you will need to take a look at and fix/improve multiple things in your software development process; as a result, your team’s productivity and effectiveness will improve.
Here are a few things that are required to make this possible. This list is not comprehensive, but compelling enough for us to take action.
Give your new employee a computer, along with his login credentials and an email account, within 5 minutes of him reporting at work.
Provide the location of the team’s software tools repository so he can start setting up the development environment, e.g. IDE, source code control, etc.
Technical documentation is any type of documentation that describes handling, functionality and architecture of a technical product or a product under development or use. For an engineer to be productive on day one, the technical documentation needs to be up to date and readable.
Keep the code base clean and compact. It should be possible to checkout a branch (or clone a repository if you are using a distributed source code control like Git) within minutes. This requires that the versioned files do not include derived artifacts or third party libraries. For example, if your application ships java, don’t check in the java binaries into the source code control – archive it in a separate repository instead, from where the packaging script can retrieve it while creating an installer. Most java projects use Maven these days and the jdk binaries are stored in a Maven repository for such projects. Another example is the product documentation, which is usually authored and stored as xml and the end user documentation is generated from these xml files and transformed into pdfs, html, MS Word or other format. Do not version these derived files in your source code control because it bloats your repository without adding value.
Bottom line: cloning a repository or checking out from a branch should not take more than a few minutes.
Code needs to be readable, should follow a consistent style, should contain necessary comments (too little comments or too many comments can both work against readability of code – a fine balance is needed). It should be possible to understand the code (with help of a mentor) on reading it once or twice. If most of the code does not make sense without somebody explaining it in detail, take that as a sign that the code needs to be improved or cleaned up.
Maintain and follow a coding standard (example here) or a code style guide. It is important for the readablity and consistency of your project’s source code. The new engineer needs to adhere to this coding style starting with this first commit.
Almost all of the code needs to be covered by XUnit tests. Without a healthy suite of XUnit based unit tests, checking in any new code (even by a senior member of the team) adds risk and every checkin needs to pass the test: “Is this change worth the risk?” To avoid this situation, a good unit test suite is a must. A few rules about unit tests (see more on Test Driven Development here):
In absence of the above, the risk of allowing a new engineer to add or change code is simply too high, let alone allowing him to checkin code on day one.
Automated system tests are the next level of checks after unit tests. A healthy automated test suite is required to ensure that changes in source code do not generate hours or days of testing to ensure regression has not happened due to the change. Also, if anything is broken, it should be detected as soon as possible. The automated system test suite needs to run at the end of the build and packaging tasks every time. System test failure should be treated seriously and issues found in this phase should be fixed within hours. The team should be in the habit of seeing the system tests pass every time. This can be many times a day or at least once a day as part of the nightly build.
The team should have a collective goal to keep the time it takes to build the entire system, down to the smallest duration possible. If it takes the build (which includes code compilation and xunit test run) more than two minutes, take that as a sign to investigate what is taking so long. For example, if you have multiple unit tests which have tests that put the main thread to sleep because it is waiting for a result – that is a bad test. Either it needs to be reimplemented in a way where waiting is not required, or it is a system test that has been implemented as a unit test.
The bottom line: compiling your entire project and running the unit tests should complete in a matter of minutes.
Even if you don’t have new engineers joining your team every week, meet the requirement that it will be possible for a new member of your team to contribute on day one and checkin a fix or a small feature. This will force you to review every aspect of your development process and improve it. Your entire team will benefit from spend more time improving the product than fixing defects. Your business will do better because it will be possible for the team to quickly turn in new features without impacting the quality of the product.
]]>That was about 2011.
]]>The thing is, we still live in a world that’s filled with opportunity. In fact, we have more than an opportunity – we have an obligation. An obligation to spend our time doing great things. To find ideas that matter and to share them. To push ourselves and the people around us to demonstrate gratitude, insight, and inspiration. To take risks and to make the world better by being amazing.
– Seth Godin in a blog post
]]>
– Source orbitvisual.com
]]>Another change with this move is that I am using Octopress to manage my blog posts. This allows me to keep my content archived on my computer, and eliminates the need for backing up the blog – just in case the service provider closes shop or looses my data for any reason. With Octopress, I am able to use Markdown to compose blog posts and that makes it worth all the trouble of moving from wordpress.com to github pages. For the curious, the raw content of the blog can be seen in the markdown format here.
There was an outage for about an hour during the time my domain name switched from looking at my wordpress.com blog to github pages, and this was due to a mistake I comitted while changing the name server entries with my domain registrar. Anyways, thats not a huge problem because this blog gets very few visits. The bigger problem due to this outage was with my email (tapan@karecha.com) which is hosted on Google Apps, and during this time, all emails sent to tapan@karecha.com failed to deliver. I am not sure if any important email was lost during this time – hope not!
Finally, everything is back up and running normally.
]]>]]>Graffiti happens at the intersection of ambition and incompetence: people want to make their mark on the world, but have no other way to do it than literally making a mark on the world.
The job of the average manager requires shift in focus every few minutes. The job of the average software developer requires that the developer not shift focus more often than every few hours.
]]>