Here's my summary of a few of those skills:
Take responsibility
When you commit to delivering something, know what your responsibilities are and what factors in fulfilling those responsibilities are within your control. If unexpected failures arise and those failures are caused by your own negligence, take responsibility for it. Own up to your mistakes.
However, don't just stop there or else it's just an excuse. Nobody wants excuses. If your dentist accidentally removes the wrong tooth, is an excuse going to replace that tooth? No. Move on from the setback and provide solutions because part of owning up to something is doing your best to correct it.
Communicate effectively
As a programmer, your job is to communicate. You communicate in meetings about software design. You communicate to the users of your software about requirements. You communicate to your co-workers or boss about better work processes. You communicate to the computer about your how-to knowledge.
Learning to communicate is learning how to present your ideas. Presentation matters. In fact, one could go as far as to say that presentation is everything that communication is. If you have an idea but you don't communicate it, it doesn't exist for others. And if you do communicate it but you do it in a way that is difficult for others to understand (maybe you use really big words) then it's not likely to spread.
The type of language that's used and its contents are the presentation of your ideas. They vary by situation but the measure of how effective any presentation is based on the same thing: how effective was it in getting what you want? People who can communicate effectively are able to get what they want. Maybe it's convincing teammates to adopt a new tool or to ditch an existing process. Or maybe it's just getting people to understand you better. They're all just changes, whether small or large, that are brought about by your communication. So the better your communication, the more influential you are.
Fix what's broken ASAP
Whether it's a bad system design decision or an inefficient algorithm, if it's causing you pain or if you know it's going to cause you pain, go fix it. Don't let it stay around for too long or else according to the broken window theory it will cause others who see it to treat the overall system with neglect.
The broken window theory is a psychological theory put forth by researchers of crime and urban decay which states that it only takes a single broken window for a new building to deteriorate into a shit hole. Why? Because broken windows instill a sense of abandonment. That nobody is home and even if they were home they didn't give a crap because there's a damn broken window. So maybe it's okay to litter a little here and there and soon the accumulation of trash accelerates.
This theory can be generalized to apply to others systems including software systems. If you leave parts of the program in a shitty condition, other programmers that work on it will likely also treat it like shit. It's broken anyway and it doesn't look like anyone is bothering to fix it - why bother? That's not the attitude you want to have - no matter how screwed a system is - because all that does is make things worse. Much worse.
I completely agree with the authors about the importance of these skills from my own experience working as a software engineer.
Learning to communicate is learning how to present your ideas. Presentation matters. In fact, one could go as far as to say that presentation is everything that communication is. If you have an idea but you don't communicate it, it doesn't exist for others. And if you do communicate it but you do it in a way that is difficult for others to understand (maybe you use really big words) then it's not likely to spread.
The type of language that's used and its contents are the presentation of your ideas. They vary by situation but the measure of how effective any presentation is based on the same thing: how effective was it in getting what you want? People who can communicate effectively are able to get what they want. Maybe it's convincing teammates to adopt a new tool or to ditch an existing process. Or maybe it's just getting people to understand you better. They're all just changes, whether small or large, that are brought about by your communication. So the better your communication, the more influential you are.
Fix what's broken ASAP
Whether it's a bad system design decision or an inefficient algorithm, if it's causing you pain or if you know it's going to cause you pain, go fix it. Don't let it stay around for too long or else according to the broken window theory it will cause others who see it to treat the overall system with neglect.
The broken window theory is a psychological theory put forth by researchers of crime and urban decay which states that it only takes a single broken window for a new building to deteriorate into a shit hole. Why? Because broken windows instill a sense of abandonment. That nobody is home and even if they were home they didn't give a crap because there's a damn broken window. So maybe it's okay to litter a little here and there and soon the accumulation of trash accelerates.
This theory can be generalized to apply to others systems including software systems. If you leave parts of the program in a shitty condition, other programmers that work on it will likely also treat it like shit. It's broken anyway and it doesn't look like anyone is bothering to fix it - why bother? That's not the attitude you want to have - no matter how screwed a system is - because all that does is make things worse. Much worse.
I completely agree with the authors about the importance of these skills from my own experience working as a software engineer.
- I've contributed to poor code that resulted in hot fixes and had to decide between making an excuse or owning up. When I own up, I take responsibility and eventually fix the mistake. If nobody takes responsibility, nothing gets fixed. Or someone else will be generous enough to fix it for you but deep down they'll start to resent you.
- Each and every day I'm in situations where I have to communicate effectively. During our morning stand ups I have to communicate the status of what I'm working on and what I'll continue to work on. If I'm not clear, others will start asking questions and the meeting gets prolonged. Also, when I'm driving during our pair programming sessions I have to constantly communicate to my partner my thinking process so they understand my intention and thus are better equipped to evaluate the code that I write.
- We maintain a few legacy systems and there are parts of it that are pretty ugly. If I need to modify it, I usually do my best to leave it in a better condition than I found it. Sometimes, however, the mess is so terrible that I don't even try to make it better. I just want to get it to work and then GTFO. I don't think that's a good attitude even when we're dealing with parts of a system we deem hopeless because you're more likely to be careless and introduce new bugs.
In addition to these three skills, there are four more skills in the chapter that I'll summarize later.
- Invest regularly in a knowledge portfolio
- Make quality a requirements issue
- Be a catalyst for change
- Remember the big picture
No comments:
Post a Comment