Importance of build engineer

Should a build belong to a build engineer or the team or the team and the build engineer?

For any small project, the build can be easily managed by the team itself. But what happen when the project grow bigger that consist of a few teams with complex integration? This is when the build engineer should come in and help to tie up the ends between the teams and take care of the integration between modules.

A build engineer that does not take the responsibility of ensuring the the whole project build is successful, will drag the whole project down. Ever encounter a build that failed for months? One of the project that I am working on, the last successful build was more that a month away and looking at the build error shown, it was due to some environment issue which is beyond the control of the development team but the build engineer.

With that, no one really know if the build ever work and throw the whole continuous integration into a chaos, and causing deployment into a nightmare for the team. Therefore, a build engineer is a very important role in a team. If the build engineer does not perform the role well, it could throw the hard work of the teams down the drain.

A build engineer that is able to manage the build well, will benefits the teams with advantages of having a continuous integration.

My personal Wiki

I am loving my personal wiki. Having installed the ScrewTurn Wiki about half a year ago, I have started to make it a habit to log all the interesting technical issue I have came across and how I resolved them. I have not share this wiki with the public as these information can be found online usually and I will be sharing thru my blog here on things that are unusual. Before this, I often keep this information in my outlook task or in some text file that things really got so messy that it became a maintenance nightmare and searching more information is tedious.

One of the main reason in deciding to have my personal wiki is due to the forgetness in me. Maybe, there are just too many thing on my mind. Another reason was that I want to have full control over it. Why? In the company I am working in, we have changed the wiki application previously and currently running two different wiki (Confluence and Sharepoint). Things keep changing and causing so much confusion that probably no one is keen to share what they have. Worst, there is lot of restriction and security impose. What you can write and what you can read.... So you might be writing something that maybe no one have access to.

Wiki is meant to be a place where information can be shared but with so much been imposed, the whole idea of sharing is loss. Sadly this might be one of the reason that slow down on how far we can move ahead. I am really looking forward to the day where everyone in the company can be sharing and move ahead together.

Report genuine bug effectively

How many times have you received bugs reported assigned to you, which you are totally clueless what the report is about? I have almost lost count the number of bugs assigned to me which I am totally unable to figure out what and where exactly the bugs is. More importantly, how many times have you reported bugs that you need to provide more information subsequently about the bug before the bug can be resolved?

The worst bug reported that I have received is a one statement description that goes like this: "This functionality (example: create member) is not working". Yes, it not working but due to what reason and what kind of error is the application or API throwing. These information are precious to whoever that are assigned to investigate the bug reported.

Reporting bugs is similar to conveying any kind of message. If your message is not understood by the receiver, then the sender is deem to fail in communicating. One of the most important principles of presentation is knowing you audience. You can imagine that you are giving direction to someone going to your house. You cannot effectively provide direction without knowing the location of the person. While providing direction, intermediate landmark should also be provided to ensure that the person is progressing accordingly to the direction you provided.

Doing yourself a favor by reporting a bug in the view of the person assigned to investigate or resolve the bug. If a user don't report a bug efficiently, then the longer it will take to resolve the issue as more collaboration is required for the whole process to complete.

Do your part and do not turn the whole development process into a bug driven development by reporting genuine bug effectively. Verify that there is a genuine error before logging it as a bug as the end to end process before the bug can be close is way too time consuming. Genuine is the key word above as non genuine bug reported is a complete waste of time and resources as the bug might be perceived by the person as an error, but it could really be a genuine error due to some incorrect behavior like missing input.