Search results for category: exoweb
Year End Thoughts ...
The year draws to a close and it is time for the yearly retrospective again. Time really does pass quickly:
- 2007 Resolutions
- 2007 Lessons
- 2008 Resolutions
Getting promoted to the level you are performing at ...
Some of the stuff I write about aren't my own thoughts but thoughts from fellow front-line managers. In particular, today's thought comes from Cindy:
You do not get promoted because you are doing your job well. You get promoted because you have been performing at the next level long enough for people to notice and reward you.
This came out of a discussion about how some people (fortunately not from Exoweb) were thinking that just because they had just started doing well at their jobs, they were due a promotion/raise. Coming from the other side of the trenches, this doesn't seem really realistic to me.
First - you never promote lightly. For the most part, you cannot demote someone. You end up having to terminate that person if you make a mistake. So until you are absolutely sure this person can perform at the higher level, you take your time with the promotion.
Second - humans have highly variable performance. Someone who is highly motivated today may be very demotivated tomorrow for no apparent reason. If what you are seeing is one of those peaks, promoting the person would be a mistake. One week later, the person could very be performing at a much lower level again. You need proven, sustained performance above the minimum level for the position to be promoted to.
Finally, a person doing well for the current position does not merit a promotion. Not unless you want the Peter Principle throughout the organization (people getting promoted to their level of incompetence.) A person doing well in their current position may get raises and bonuses, but never a promotion. Proof that one does well at the current position is rarely proof that the person would do better at a higher level. The skills are often different. The skills required for a software developer are different from that of an architect, project manager, etc.
We Make It Up As We Go
Every now and then I find myself repeating the same thing in weekly chats, so I try to note them down in a blog post so the Exowebers that actually read the Exoweb Planet have a chance to see it. This particular one has to do with how we developed our work processes and best practices. There is no mystical method, no profound MBA insights or deep pondering. Quite simply, we make it up as we go.
That's not to say all our current processes are arbitrary. Every process or practice we have, we evolved to overcome a perceived problem. We experiment with different processes and those that work, we kept. Those that failed we learned from and moved on. The entire organization is a work in process, continuously trying to improve itself.
There are a few core values we do have, which very much reflect those of agile methodology: People over process, working code over documentation, etc. We also believe very much in making this a great place to work. Since you spend a huge portion of your waking hours at work, why wouldn't you want to make it as pleasant, as fun, as challenging a place as possible?
From these core values we simply figure things out as we go. For example, our current process of code reviews was triggered by the realization that our code quality wasn't good enough, that too much bad code and bugs were leaking into production systems. We tried the NASA style group code reviews but found that much too heavy. We then tried having a couple of core code reviewers doing all the work, but found that it did not scale and that the benefits of code review actually were disproportionately accumulating with the core reviewers. Our current method is a lightweight team review process that seems to combine the benefits of code review while reducing the cost. We are likely to make more tweaks and changes in the future, depending on future needs and ideas.
What does this mean for Exowebers? Most important of all, it means that it is the past ideas of all of us that have created the great environment we have. It means it is your future ideas that will make us an even better place to work. You need to pay attention to your environment, be willing to question our processes and methodologies, and contribute new ideas when they come to mind. No process is sacred. Given good enough reason, visible enough benefits, anything can be changed.
You can contribute ideas openly, by floating RFCs by email, or you can quietly suggest them to your team leaders in weekly chats. Whatever method you choose, it is important that the ideas are communicated and considered. Only then can we as a company improve. Only then can we make this place an even better place to work.
Yes, this includes higher salaries too. If you have ideas on how to make us more profitable, we can all share in the profits in the form of higher salaries :)
Things I Would Like to See More In My Teams
Overall, I'm working with a great bunch of people, so don't let the topic mislead you - I'm really happy with the people I work with. However, nothing's ever perfect and there's always room for improvement. The following are things that have recently made me stop and think, "I wish I saw more of that ..."
- Curiosity
- Sharing of information
- Dissatisfaction
3 Questions ...
This is the English version of Cindy's "3 Questions" blog post, written from a different viewpoint. As a bit of background, Cindy and I are both managers in Exoweb and one of our responsibilities is to carry out weekly chats with the people in our teams. Both of us have been asked these questions before and we figured it would be of interest to Exoweb people in general. I'm writing this without having actually read her post, so it should be interesting to see how our viewpoints differ.
The questions are:
- Does Exoweb give team members a chance to switch career paths?
- Are personnel evaluations transparent?
- If an employee makes a mistake, how will the company handle things?
The Three Aspects of Management
Found myself explaining for the third time in a day yesterday about the three different aspects of management that I deal with in my work in Exoweb. Thought it best to blog about them, to put down in writing what I have had to repeat multiple times last week.
These are my personal opinions/divisions of course and have no grounding in scientific research. They are merely based on personal experience. However, all managers in Exoweb perform at least one aspect and some can do all three.
In my daily work, the three aspects I end up spending my management time on are:
- Tech Management
- Project Management
- Human Resource Management
2006 Year End Thoughts
Can't believe another year has come and gone. It seems like only yesterday that I wrote the 2005 Year End Thoughts, and only a few days ago that I came back to China and started my career in Exoweb. Time really does fly when you are having fun, and I certainly have been having a great deal of fun in the last few years. Sometimes stressful and sleepless fun, but fun all the same :)
General summary of thoughts:
Things that I am happy about:
- Exoweb
- Teams improving, growing
- Culture
- Personal
- Facing the different challenges over the last year
- Learning to delegate
Things that need to be improved:
- Exoweb
- Giving back to FOSS
- Creating a continuous learning culture
- Personal
- Working with people
Goals for 2007:
- Make self (almost) redundant
- Teach, not do
Time To Turn In My Geek License
Apparently, I'm spending too much time doing management and turning into a PHB. No one seems to think I'm technically competent anymore. Some recent conversations:
While training a junior project manager:
Me: "So remember, with new tickets, ask a technical senior to help you estimate how many hours are required to complete the task ..."
A few days later, during the usual morning meeting discussing what tickets to create, prioritize, etc:
Me: "... so I think we should put this task in Milestone x, priority critical, estimated time 8 hours"
Jr: "Ok, sounds good. I'll go get an estimate from senior x and take care of it."
Me: "Wha ... didn't I just give you an estimate?"
Jr: "Yes, but you said I needed an estimate from a senior ..."
While showing a relatively new developer the rankings of everyone in Exoweb:
Me: "... and here we have the mid-levels devs, split in 3 sub levels. Finally, these are the seniors ..."
Dev: "Wait, you're considered a senior?"
After relating the above two incidents to yet another developer:
Me: "... so apparently they don't think I'm a senior anymore ..."
Dev: "Well, if you don't tell them, it's not obvious ..."
If anyone wants me, I'll be out getting a haircut, buying some suits and gaining a lot of weight ...
KISS (or why MS CS students have a bad time in interviews ...)
It's that time of the year when Master's students are hunting for jobs in China and we are flooded with resumes from students with Masters of Science in Computer Science (MScCS). We've spent the last couple of weekends interviewing the candidates that passed the front interviews and it has not been pretty. In fact, it has been pretty sad.
The biggest problem we encounter with MScCS grads is made very apparent in how they approach one of the our typical programming problems. This particular problem is fairly simple and with a little bit of thought, can be made into a linear (computer performs x more calculations for every element added to n, where x is a constant number) or O(n) type of equation. Most competent people will come up with a O(n^2) algorithm (computer performs n operations for every additional element added to n, resulting in rapidly increasing number of calculations per element added) to it at first, then after a little thought, realize that there are a lot of duplicated operations, refactor that out and come up with the linear solution.
MScCS are a little different - almost all the ones we have interviewed to date encountered this problem, probably came up with the O(n^2) equation ... then went off the deep end. They would inevitably come up with complex, fancy algorithms that utterly failed to solve the problem. These fancy algorithms would often handle the common case but fail on the boundary cases. They were fragile, easily tricked or prone to failure. When these flaws were pointed out, these candidates would come up with even more complex algorithms or add a lot more if/else checks ... resulting in even more brittle and unreliable code. None of them, if unaided, could come up with the ideal solution.
Well, that's not really true. One particular candidate, after coming up with 4 complex, unworkable algorithms, finally said, "well, since you have given me such a tight time limit, I have no choice but to brute force it." He then proceeded to give the ideal solution. Linear time, handles all boundary cases. But he would rather give 4 non-working solutions rather than the working, "inelegant" solution.
What I find strange and rather disturbing about these interviews is that it is somehow related to the mindset of those who are doing their MScCS. Bachelor level grads or people with several years of working experience rarely make this mistake. They either do it right or not at all. Yet for some strange reason, the MScCS students seem to value fancy algorithms over _working_ algorithms.
Maybe it's the MScCS curriculum here in China which tries to focus on fancy algorithms. Maybe it's just that the MScCS feel the need to prove that their abilities are above the norm for CS graduates. Maybe we just have incredibly bad luck with our candidates. Whatever the reason, extremely few MScCS fresh grads have passed our interviews. As you can imagine, in a production environment, we highly value working code and eschew the fancy algorithms, especially algorithms that needlessly complex. Simplicity and correctness is far more important in our craft.
The famous quote attributed to Brian Kernigham comes to mind:
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
When writing algorithms, another quote from Agile development comes to mind - "do the simplest thing that can possibly work." Keep It Simple ... er, let's call it Keep It Stupidly Simple (KISS) and avoid insulting anyone :)
Full Emacs Keybindings in OSX
One fun thing about reading blogs - you learn little gems that you wouldn't encounter otherwise, sometimes even when you search for it. When I got my Mac in August last year, I was thrilled to find that it supported emacs style key bindings in most Cocoa applications. However, it wasn't complete support - while all the control key bindings worked (^f, ^b, ^p, ^n, etc), the ALT/option button bindings did not. So I missed useful keys like page up (Alt-v) or forward one word (Alt-f).
I did spend a couple of hours searching on this, particularly in the help documents and knowledge base contained in the Mac and on google. No luck. I eventually resigned myself to working without the Alt keys and chugged along mostly happy. That is, until today, when I read Erica Sadun's blog on the Mac DevCenter RSS feed.
Turns out that all I really needed was this Apple Developer article on Key Bindings in OSX, including Emacs examples. It was as simple as adding my own custom definitions in ~/Library/KeyBindings/DefaultKeyBinding.dict.
The OSX key binding capability is actually quite impressive. You can even do multi-keystroke bindings, such as ^x^f (if you really miss Emacs that much).
Another day, another great functionality to rave about in OSX :)
