Glamping是Glamorous和Camping 兩個字合成出來的, 是豪奢露營.
283 total views
Category: Alan’s Notes
How to convince a software engineer
Somehow, the software developers I’ve met were very difficult to convince. Even as simple as using tabs in code for readability. I, at times, were difficult, too.
I found a script one day. It worked most of the time, if not every time.
I asked engineers to have the product send out email notifications when the product runs into an issue. As usual, they passively refused to do so. One day, at 6 pm, I found R sitting in his cube. I asked “R, shouldn’t you go home now?” He told me he was waiting for a long-running ETL script to finish. He needed to babysit the script so that if there were any errors, he could take care of it as soon as possible. I said that you should implement the email notification so that you can go home and only hop on then computer only if you got an alert.
They key is to tie the desired behavior to their benefits. Since then, I have been using the same trick.
If one is going to have a long vacation, I would ask him/her to document things like how to support the product, troubleshooting steps, etc. so that I don’t have to call him/her to be log in to fix the issue while on vacation.
286 total views
讓人難堪 英文
信守諾言 英文
Developer Metrics
Sports have a lot of numbers to gauge how good a player is. In baseball, there are batting average, ERA, etc. I had been wondering about software developer metrics. We can judge how good a developer is by reviewing his code, but that is very subjective. I’d like to have metrics that show how a good developer brings values to the company.
When I got my second management position, I got my chance to try to develop and implement the metric. Luckily, I also go have a great project manager to work with. He helped collect and report the numbers.
Here are the metrics:
Net Daily Burn: This is the typical velocity in Agile per developer/working days. In a typical iteration, NDB is burned/days in an iteration. However, people can get sick or take vacation. We changed it working days. So this metric tells me how much work the developer can burn per working day.
A higher ADB tells me the developer is good. It could be that the developer works hard(long hours) or is very smart and efficient. For example, if the task is to time how long all data access methods take, instead of writing system.out.println in every data access method, he/she uses AOP.
Average Daily Burn: This is ADB + other dev tasks that are not considered when the estimates were made. Our typical ‘other dev tasks’ are extra time to deal with build issues, unit testing, etc.
428 total views