Posted by Sam on Feb 22, 2008 at 12:00 AM UTC - 6 hrs
I'm going to keep this week's post about My Job Went To India short,
because the two quotes I want to pass on from Chad pretty much sum it up:
You work for a business, and unless you provide some kind of real value, you are a waste of money.
So you need to consider what you cost the company - not just your salary, but include your benefits
and anything else as well. Compare that with the value you provide. Are you worth it?
You don't need to just meet your cost - Chad mentions that's like putting all of your savings in a
0% interest account. The value you provide needs to exceed your liability.
To get there, ask yourself about it regularly:
A month would pass and I would think, "What did I deliver this month?" Then, I started
getting as granular as weeks an days. "Was I worth it today?"
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Posted by Sam on Feb 29, 2008 at 12:00 AM UTC - 6 hrs
I want to share some words of wisdom with you again that I've shared in the past
from notes I took in Dr. Ricardo Vilalta's course on Machine Learning:
If you claim to know something, you will be seen as the expert
Therefore, be honest about what you really know
Be willing to learn and admit your lack of knowledge on certain areas
Don't claim you are superior to others
Don't give in to the pressure of winning over others
This week, I'm diverging from the advice found in My Job Went To India, and offering some
advice based on personal experience, with the above caveat.
Most people don't talk. You might be one of them. But why don't you talk? You have an
opinion don't you? Questions at least?
I think a lot of it has to do with item 1 on the list above. If you claim to know something,
you open yourself up to criticism of your opinion and being proven wrong.
So, you have to be honest about what you know. But you're not confident enough in your
knowledge, so you pretend to know more than you really do. Doing that, you have to
keep state in your head, whereas, if you were "willing to learn and admit your lack
of knowledge," you could essentially be speaking functionally
(paraphrasing Paul Graham, Interview with Jessica Livingston in
Founders at Work).
So instead of saying something, you sit silently, hoping no one will ask you anything
The problem with that approach, of course, is that you don't ever get to shine.
Rarely ever will anyone who occupies a position of importance see your brilliance, your modesty, or your sense of humor.
In fact, you might be lucky if they remember your name. (Unless you do something boneheaded.)
You don't have to be the smartest person in the room. You'll be wrong sometimes -- maybe a lot.
But if follow the list above, you'll be miles ahead of the wallflowers - even those who have more skill
and knowledge than you.
So how do I know speaking up works?
I've been trying it.
And what kind of results have I had? Outside of relationships cultivated through this blog and my
other online activity, in the
past six months I've been offered three jobs, none of which I initiated. (And even though you might say the blog
is an example of "speaking up", I'm excluding that to show you don't need one to get
the same effect, though it may amplify it.)
They aren't "work for free until we make it" jobs either - in fact, two have been from people I know
and respect (the other one was from a relative stranger, so I didn't consider it very seriously). Both of those have been from people I already admire
for their skill, knowledge, and accomplishments. Both are from people I'd love to work with
and in both positions I'd be doing work I'd enjoy.
Can job offers translate to saving your job? I think so. If other people want you, surely
someone wants to keep you. (And if not, you've got other sources from which to pull income!)
Posted by Sam on Mar 07, 2008 at 12:00 AM UTC - 6 hrs
You might not want to hear it, but you can be replaced. Indeed, you should strive to be replaceable - or at least tell yourself you are. That's the subject in this week's
advice from My Job Went to India.
This is an eye-opening, scary, yet inspiring chapter - all rolled into one. In it, Chad explains why we should strive to be
replaceable parts in the machine (or "a pebble in a bucket of water"), and he mentions the old job insurance via crapcode line:
I've heard lots of programmers half-joking about creating "job security" with unmaintainable code. And, I've seen actual programmers attempt to do it. In every case, these people have
become targets. Sure, it was scary for the company to finally let go of them. Ultimately, though, fear is the worst that ever came of it. Attempting to be irreplaceable is a defensive maneuver that creates a hostile relationship with your employer...
By contrast, being "replaceable should create an unhostile working relationship," Chad says. He also notes that if you're not replaceable in your current position, you can't move up the ladder.
You might like to imagine yourself as a supercoder, keeping your company safe from disaster, and that if you were gone, they'd be helpless. To combat this delusion, Chad suggests imagining the average impact of one of your co-workers leaving.
I'll wait while you imagine it.
Got it? Good. That's probably about the same impact you'd have. If your entire company's truck number is a 1, and you're one of the ones, then clearly that's not the case for you. If you are in that position, you should be doing something to reverse it. It's unlikely you're "so peerless that [you] in fact should be irreplaceable" (quoting Chad Fowler).
The best part of this chapter, though, is the story Chad tells about a powerful CIO in a powerful company:
He and his team (of which I was a part) were winning every award and setting every IT standard in the company.
[Yet] he professed to waking up every day and intentionally and explicitly reminding himself that he could be knocked off his pedestal any day. Today could be it, he'd say.
[Chad explains,] humility is not just something we develop so we can claim to be more spiritual. It also allows you to see your own actions more clearly... [The] more successful you are, the more likely you are to make a fatal mistake. When you've got everything going for you, you're less likely to question your own judgment. When the way you've always done it has always worked, you're less likely to recognize a new way that might work better. You become arrogant, and with arrogance you develop blind spots.
In my case, our truck number is a one. But we have so few employees, it's hard to get it much higher than that. Still, we're making moves in the right direction to increase our truck number so that we all share more knowledge about more of each others' positions. Our hope is that while one of us might not be able to take over for another (if for no other reason than lack of available time), we might have enough shared knowledge to train someone else to do it, without it being more difficult than it needs to be.
All that spaghetti code I wrote is slowing being shoveled into the dumpster. And we're skipping the recycle bin.
Posted by Sam on Apr 04, 2008 at 12:00 AM UTC - 6 hrs
We're all going to fail at some point. I've failed, you've failed. We'll both do it again.
And who cares anyway? It's a good thing to fail.
Failing is how we learn - if you're not failing, how likely is it that you're doing something new?
You probably don't think of it as failure though. But it is - it's just that we prefer to fail
early and often with small mistakes, as opposed to late and rarely, with collossal mistakes.
Failure, and how to react properly to it, is the subject of this week's chapter in Chad Fowler's MJWTI.
Chad notes that since failure is a given, "within reason, we don't judge each other on the mistakes we make."
Instead, we tend to focus on how we react to that failure.
For me, Chad best summed it up by comparing it to failure in the food service industry:
Think about the last time you experienced a customer service issue at a restaurant. Perhaps you
waited way too long for the wrong dish to ultimately reach your table. Think about how the waiter
reacted to your complaint.
The wrong reaction is for the waiter to make excuses or blame the cooks.
The wrong reaction would be for the waiter to walk off to resubmit the order and stay out of sight while
you site there starving and wondering when the hell your food is going to arrive. Of course, the really
wrong reaction would be for the waiter to arrive with a dish that he already knows is wrong, hoping you
would either not notice or not complain.
In each of those cases, it may even seem like the wrong thing to do is the natural thing we want to do.
But put yourself in the customer's position (in whose shoes, no doubt, you've been). How would you like him to react?
Exactly the way you should react (quoting Chad):
Raise the issue as early as you know about it...
Take the blame [even if it's not all your fault]...
Offer a solution ... [or] a plan of attack for finding [one]...
Ask for help.
It's a hard thing to do to put your ego aside like that - but offering solutions instead of excuses goes a long
way. Lately, I've been trying that - and for me it's an extra hard thing to do. I like to argue. So when
I'm wrong, it used to be near impossible to admit it and move on.
But having used the technique, I can say it's much nicer to own up to it instead
of squirming around trying to find excuses. I'd even go so far as to jump in if you notice someone else
playing the blame game. It's not useful at all to assign blame. Fixing problems, however, is useful.
So instead of saying "I didn't have time," or "I had a problem with such and such," I've been trying to
use the following key phrases (These are some recent examples, boiled down to their essense):
I didn't get that done. I don't have a good excuse. I'll get it to you this evening.
I should have done that. Let's fix it now.
I was mistaken in my original thought. Here's a more accurate one. Can we work something out?
That reminds me - I blamed something on my battery going out yesterday. It was the truth, but I probably
could have offered something better. I probably should have said the first thing on my list.
When you make excuses for your mistakes - especially when they just keep piling on and they're all out of your control - it sounds ridiculous to the other people listening. It's incredibly more useful to
offer solutions. And even if your battery did die, or something out your control did
prevent you from meeting your responsibilities - don't pause after saying so. Don't let them have a chance
to respond before you say "I'll fix it" in a tangible and timely way.
Aside from the learning aspects involved in failure, reacting in the the right way provides a chance
to shine. I conclude as Chad does: "Stressful times offer the best opportunities to build loyalty."
Use them to your advantage.
Posted by Sam on Apr 11, 2008 at 12:00 AM UTC - 6 hrs
I do say it quite a bit - but this is still something I've got to learn to do more often. Even though I try to say "no" when I know I can't do something, I have still been feeling over-committed lately. So it's time to start saying it more often.
But the fact that I feel over-committed is just a symptom that I'm saying "yes" too often - the real problem is that I'm lying to whomever I'm making promises that I can't keep. In this week's chapter from My Job Went To India, Chad Fowler sums it up:
Saying "yes" is an addictive and destructive habit. It's a bad habit masquerading as a good one. But there's a big difference between a can-do attitude and the misrepresentation of one's capabilities (extra emphasis mine). The latter causes problems not only for you but for the people to whom you are making your promises. If I am your manager and I ask you if you can rewrite the way we track shipments ... by the end of the month, someone probably asked me if it could be done by then... So, armed with your assurance that you can make the date, I run off and commit to my customers that it will be done.
When you lie about your capabilities (even though it's not malicious), that spreads itself throughout an organization, and harms everyone.
Most importantly for you, it damages your reputation. Whereas the man who says "yes" only when he is truly capable may feel bad about having to say "no" more often than you, he will come to be known for his honesty and accuracy in prediction while no one will trust anything you have to say about such matters.
The point is that you need to have the courage to speak up on the job. You need to say yes when you can do something. You need to say no when you can't do something. And as Chad notes at the end, you need to speak out against bad decisions:
As a manager, I make decisions or strong suggestions all the time. However, I don't hire my employees to be robots. It's the ones who speak up and offer a better suggestion that become my trusted lieutenants.
How guilty are you of over-committal and non-committal? I may have learned to not keep quiet, but I still have some work to do regarding the scheduling of -- and commitment to -- tasks in general.
Planning helps make you effective. I've said it many times - I like to spend a few minutes each evening planning what I'll do the next day. I may get in trouble when I'm in Windows because I've yet to port my time-boxing routine over there, but for the most part, it really helps: I always have a specific direction, and I get to think about it in my dreams.
"Say it, Do it, Show it" - That's the advice this week from Chad Fowler in My Job Went To India. This chapter came at a perfect time for me - my planning is slipping, things to do are piling up, too many people want too many things from me, and I can't seem to decide what to do because there's too much to choose from. (Let me whine some more.)
Chad offers a lot of good advice in this chapter. The first illustrates why planning is so effective:
As you complete each item on the list, mark it DONE. Use capital letters. Say the word, done. At the end of the day look at your list of DONE stuff and feel like you've accomplished something...
It's a stimulating process. It's rhythmic. It allows you to divide your days and weeks into a series of small victories, each one propelling you to the next. You'll find that not only does it give you visibility into what you're accomplishing but you'll actually get more done than if you weren't watching things so closely.
(Link and emphasis are mine.)
Even though my daily plans help me stay focused and get things done, they are only tactical in nature - which means that although I consistently have a direction, there is no coherent strategy to it. That's why coming across this chapter again was so fortunate: once you've "established a rhythm of plan and attack," you should start working on a more strategic level of weeks and months. It's something I've not done: I may have an item on my to-do list that doesn't need to be completed until 90 days from now, but that doesn't add up to coherence.
I've recently been trying some organization practices from GTD (without having read the book), so we'll see if that also helps.
Other than planning and executing, there is a third practice that Chad identifies as useful at work: telling your manager.
You should start communicating your plans to management. The best time to start communicating the plans is after you have gotten through at least one cycle of the plan through execution. And -- this is an important point -- start doing it before they ask you to do it. No manage in his or her right mind would be unhappy to receive a succinct e-mail from an employee stating what was accomplished in the past week and what they plan to do in the next.
I'll think I'll try that.
To summarize the last two weeks, I'd say that the ability to say no and the ability to commit (and execute), while opposites, are still both required skills. However, you should commit only to the right sorts of tasks for the right reasons, and refuse to give in to pressure to candy-coat your answers in the affirmative when you really think the opposite.
Anyway, I'm interested in what you have to say. Got any planning tips, or stories (good or bad)?
Posted by Sam on Apr 25, 2008 at 12:00 AM UTC - 6 hrs
It's comfortable to play the idealist and pretend you don't care what other people think about you. But, that's a game. You can't let yourself believe it. You should care what other people think about you. Perception is reality. Get over it.
The main thing I want to do here is dispel this myth that marketing is evil, or that it's "just for suits" (quoting Fowler). There's no sense in persisting these illusions that say your super-modesty is an ethical choice in reaction to evil, or that it's not your job.
I cast dispel magic in your general area. I rolled a 17 on a d20. It's enough to pass the check. Therefore, the illusion from which you now suffer will disappear on your next turn.
I agree that it is possible to go overboard, being a braggart. But let's worry about that when you get close to it - you're most likely on the other end of the scale:
Most programmer types were the last kids picked for every team when they were in school. They probably avoided social situations where possible and failed miserable where not possible. It's no surprise that these people are afraid to stick their necks out by trying to show someone their capabilities.
The fact of the matter is that there's no reliable way to objectively measure knowledge-workers. What are they going to do? Count the lines of code you write? LoC as a measure of productivity is a stupid idea. Even if you were to have objective measures of "goodness" and "badness" as it relates to developers, perception would still matter: Someone has to decide if he likes you enough to promote you, or to keep you on the team in times of cutting back, or hire you in the first place.
If people are going to rely on their perceptions to form judgments of you,
you might as well be the one to decide what they experience to form that perception.
One way to do that is to Speak Up! In doing so, Chad suggests making a list of groups you interact with and their associated perception drivers. His example looks like this:
Technical skills, social skills, teamwork
Leadership ability, customer focus, communication skills, follow through, teamwork
Customer focus, communication skills, follow through
Communication skills, follow through, productivity, technical skills
He also suggests making your own list, and trying to change your behavior to emphasize those points which resonate well depending on which group you're around. Critique yourself as you go along. By simply making conversation along the lines defined by perception drivers in each group, you don't need to brag to be seen in a positive light.
It sounds quite technical, but I think it's probably a bit more natural than it seems by writing it down and reading it.
I know I need to give it a try. Yesterday, one of my classmates made a "he talks too much" motion with the duck-quacking of his hands when he thought I wasn't looking. I know it was probably something to do with the way he was feeling, but I could obviously be better perceived at least by that member of my peer group.
What do you think? Baloney? Hogwash? Or might there be something to this perception thing? My vote's with the last one. Don't agree? Change my mind in the comments.
Posted by Sam on May 02, 2008 at 12:00 AM UTC - 6 hrs
To market yourself effectively, and thus, improve your career prospects, you need to know how to communicate effectively. It's not just that communication "gets the word out" about you - it has value in and of itself.
There are many ways to communicate - and you should practice them all. In the post linked to Raganwald above, Reg talks about physical communication (as opposed to virtual) and suggests volunteering to present in front of a group as a means to improve your communication skill. It's something I get some small practice with at school, and something which I'd like to eventually do more of in a professional capacity - but I've yet to take the time or show the cojones and actually do it, outside of what's been required of me.
Anyway, he covered it better than I will, so I'd suggest reading it over at his blog. I'll continue with the real point of this one, about not being a "grumpy old code ogre [whom] everyone fears" (Quoting Fowler, pg 125).
Managers and customers are
responsible for something gravely important which they ultimately have to trust to some scary IT guys for implementations... In this situation, what's the most important attribute they're looking for in a team member? ... It's not whether they've memorized the latest design patterns or how many programming languages they know.
They're going to be looking for someone who can make them comfortable about the project they're working on... They're afraid of you.
Recognizing this deficiency in the relationship, you can bridge the gap by reversing the polarity: try looking at your customer or manager as the one on whom you depend for information about it and without whom you could not do your job (that's the case anyway).
I try to do this, but it's hard to tell how effective I've been. Chad suggests finding some email you've written to a manager or client, telling your mom it was written by a colleague, and asking her how it could be improved. That may work, but I don't know if I'm willing to try it. He also says going through old mail yourself will help give you a more objective perspective into your own mail.
Of course, this type of thing isn't for everyone. As one commenter over at Reg's post points out:
Rag, see, we don't want to improve our careers, exactly because an improved career would mean more communication and less code. And we became programmers exactly because we wanted to be spared of that "Hey, how are you, is everything fine?" kind noise most biped animals call "communication", and rather talk to a computer which does not expect any more information than it actually needs to do it's job.
That's the kind of programmer I used to be. Obviously, I've tried to move away from that in recent years. However, it's certainly not a view about your job to be ashamed of: I think an overwhelming majority of us got into this because we were socially awkward. But, I'm not sure the types of jobs where you can do that are going to be around forever. I hesitate to say, "much longer," because I have no idea, to be honest.
The point of it all: This goes beyond simply speaking up. You want to be the "adventure tour guide:" hold hands when you need to, help them navigate the treacherous landscape. Being helpful and somewhat outgoing puts people at ease, where terse messages loaded with talk about details they know nothing about does the opposite.
You want to be open, not shut off.
Do you have any tips for communicating well with non-technical people?
Using acronyms and abbreviations that come from the online subculture is acceptable in certain situations: IM with friends, twitter (where space is limited), and texting are three of them. An email to your boss, coworker, or a client is generally not.
Most people (but if my experience is worth anything, not even close to everyone) are fine in the area of not deliberately writing like that when communicating in some official capacity. So, in the "Me Rite Reel Nice" chapter of My Job Went To India, Chad Fowler focuses more on unintentional mistakes. He relates research that found
more than half of companies consider writing skills when making both hiring and promotion decisions. Forty percent of surveyed companies in the services sector said that a third or fewer of their new hires had the writing skills they desired.
Furthermore, Chad describes the necessity of knowing how to write well: As companies and teams move to a more distributed global model, much of your communication will be with the written word.
Unintentionally riting bad - fillng ur txt w/ speling and gramer mistakes can make you look sloppy, [im|a]mature, or even ignorant.
Sound like an easy way to stand out? See that red underline on the screen? That often indicates a spelling error. See if you can fix it. You wouldn't let that stand in your code would you? So why let it stand in your writing?
Posted by Sam on May 16, 2008 at 12:00 AM UTC - 6 hrs
I like email. It has so many advantages: The asynchronous nature means I can respond when I have time and you can do the same. I don't have to face you, so its easier to relate unpleasantries. I can take as much time to carefully craft my words as I need. I can say just the right thing. The list could get longer.
A lot of us really like computers more than we like people. We prefer IM or IRC to picking up the phone, and we prefer email over face-to-face conversation. Be honest, you'd rather be talking to Johnny 5 than Homo sapiens.
The problem is that most of the rest of the world doesn't share your distaste for people, and neither would you if you were depending on the person who chose not to communicate on a personal level. To put a similar amount of information in an email as you could get in one RL conversation could take tens of minutes to write (and subsequently read) compared to just a couple of minutes.
Just like Johnny 5, humans need "more input, more input!"
As Chad Fowler notes in the "Being Present" chapter of My Job Went To India, business is personal. The bonds you form (or don't form) with your boss and coworkers affect how they treat and react to you. As he writes on page 131,
The natural work mode of a computer person is to hole up in a cubicle or office, put on a pair of headphones, and get into "the zone" until it's time to eat. Douglas Coupland, in his book Microserfs tells the entertaining story of a team having to buy flat food to slide under the office door of a programmer on a mission. This kind of isolation has become part of the culture and folklore of the software industry.
Unfortunately, speaking for your career, this is bad for business. If you're locked up in an office, accessible only by phone (if you answer) or e-mail, perhaps even working all hours of the night and sleeping late as a result, there's no difference between you being onsite with your bosses and your customers and being offshore. [Bold emphasis mine.]
No difference, except you probably get paid more. So how valuable are you then?
You are on-site and that puts you at an advantage. Use it. As I mentioned above, if the tables were turned - if you were depending on someone else - you'd not likely feel like a few short emails will suffice for communication.
From my own recent experience, I can certainly say that's how I've felt. In this case, I'm the customer forking the money over to my home builder. When we first met, he said he preferred communicating mostly through email. I thought to myself, "great, I won't have to call him or meet with him all the time."
That quickly changed as I noticed problems with the house. I wanted vocal reassurances. I wanted face-to-face meetings so I could express my displeasure with the tile not matching without coming across like a jackass in email. I wanted to know when problems would be fixed - not just "I'll fix them" with no progress seen over two months. A simple, "We fix that kind of stuff at the end" would have gone miles. Sadly, I've only met with the builder a couple of times and spoke on the phone even less.
I'm completely uncomfortable with the situation. I feel out of control. I want to know what's going on and how we're going to fix the problems. But I get no reassurance - at least not as quickly as I'd like it.
Now I know how my customers and coworkers and bosses feel when they don't get anything but short emails from me. They have queasy stomachs and feel sick. Hopefully, I won't let them feel like that again.
Posted by Sam on May 23, 2008 at 12:00 AM UTC - 6 hrs
You wouldn't market a product to American audiences in German. A soft drink company wouldn't
try to sell a drink to consumers based on the measured quantity of red dye #8 it contains. Common
sense tells you that to sell a product to an audience, you have to speak to that audience in a language they can both understand and relate to.
-Chad Fowler, My Job Went To India, page 133.
In other words, when you market yourself, consider to whom you are doing the marketing. Consider the perception drivers that define what a particular group responds well to, and use language that they understand. As Chad notes, "businesses and those who run them are interested in business results," so it's unlikely your discussion of the latest inversion of control framework is going to move them. Focus on why and how that helps the business.
Of course, that is in general. Clearly there are some companies where management knows quite a bit about the details of technology. Still, the role they are playing dictates they care about how that technology affects the business goals, not the other way around.
Can you automate TPS reports? (Can I reference anything else in that movie?)
Can you show them the light and get them to ditch ceremony in favor of essence when it makes sense?
IronRuby now runs unmodified Rails.
And JRuby's been on Rails for a while. There's Groovy and Grails and IronPython and ColdFusion and Jython and Scala and frameworks in the platform-anointed languages that relieve pain points in Java and .NET (while still running on them and integrating well!). It's true - they make Vicodin for the programmer's broken spirit. Chicken noodle soup for the coder's lost soul.
So why are you still always writing home-brew apps from scratch with all the pomp required by Her Majesty?
Can you sell essence to your boss and coworkers?
You can start unit testing. You can set up source control. You can tell people when you think their ideas are wrong, and fix other WTFs as you encounter them.
Then no one will need to ask what you do. They'll know.
Ruffled any feathers lately? Been a force for Good? Let's hear about it!
This week we take a look at the other side of networking: not how you can become a good coder, but how you can get gigs easier than other people can. "Let your voice be heard" is what Chad Fowler titled this chapter in My Job Went to India, and looking back on it, this must have been one of the most inspiring chapters in the book. My outward-facing career plans follow his advice quite closely.
It's all about networking with people -- how you might do it and why it works.
Lee LeFever explains the concept in under two minutes:
Although Lee focuses on social networking websites, the concept applies more generally.
Chad explains it using the best words I can think of. In essence, this is what I'm talking about when I say "my outward-facing career plans follow his advice quite closely."
The world is changing. If you want to write your ticket, you've got to think bigger than the IT workers of yesteryear. While moving from level-23 Programmer to level-24 Programmer Analyst might really be your short-term career goal, as a programmer today, you need to think beyond the next promotion or even your current place of employment.
Set your sights higher. Don't think of yourself as a programmer at a specific company -- after all, it's not likely that you'll be at the same place forever -- but as a participating member of an industry. You are a craftsperson or an artist. You have something to share beyond the expense reporting application you're developing for your human resources department or the bugs you've got stacked up in your company's issue tracking system.
Companies want to hire experts. While a resume with a solid list of projects is a good way to demonstrate experience, nothing is better at a job interview than for the interviewer to have already heard of you. It's especially great if they've heard of you because they've read your articles or books or seen you speak at a conference. Wouldn't you want to hire the person who "wrote the book" on the technology or methodology you're attempting to deploy?
Being good is important, but it doesn't get you all the way there. Our industry ... is a big, complex web of people connecting each other. The more places you are attached to the network, the better your chances of connecting with that perfect job or career break. Limiting yourself to the company you work for places serious limits on the number of connections you can form.
It's not like I read this and said, "that's what I'm gonna do!" I didn't even remember it until I reread it this morning. But something there stuck with me. Although I had toyed with the idea of starting a weblog before I read this, it was that text that got me off my ass and made me actually do it.
That's the what and the why. But how do you get there?
I'd start the same way I started finding and being a mentor (same link as above). This is what I wrote back then, and I think it shows the stumbling quite well:
I started becoming involved online - asking and answering questions in topics of interest to me. Answering questions is particularly beneficial, because you get to throw ideas into the arena and see if your expert "mentors" will disagree with you and correct you when you are wrong. In fact, there's nothing on this blog I enjoy more than when someone disagrees with me in a comment* (with substance, anyway). On the other hand, when you are right you learn that you are right and you reinforce that knowledge.
I also made it a point to sit in the front row (or close to it) of every class and ask questions to aid in my understanding of the subject matter. I started visiting conferences and talks and user group meetings to learn from other developers when time permits. Some friends and I organized the UH Code Dojo in an effort to have mentors and be mentors. Another friend or two are helping me progress in .NET faster than I would alone and we're throwing around the idea of forming a game development meet-up group. I started reading blogs and participating in comments on various topics on a regular basis, rather than just when I needed to find information on a particular problem. Several blogs cover languages or topics I rarely use. Some cover things I've yet to use at all. Finally, I'm planning on going deeper into bioinformatics and game development with the advanced courses next semester, where the one-on-one time with the professor is much more like a mentoring relationship.
Read blogs. Comment on them. Start your own. Get involved on the mailing lists. Join a user group. Start one. Speak at one. Submit papers to journals and talks to conferences. Submit articles to other blogs or industry magazines. (Paraphrasing Chad Fowler, pp. 138-139)
I've barely started. I still need to get more involved in the user group scene, to be followed up with some conferences hopefully. I could also stand to publish my writing in places other than this weblog. I'm moving in the right direction, but I've still got a ways to go before I'm satisfied with what I've done.
That's me. Now I'd like to hear about you.
In what ways are you building your network, even if unconsciously?
Posted by Sam on Jun 20, 2008 at 12:00 AM UTC - 6 hrs
The internet has given us an amazing opportunity to "build [our] brands," as Chad Fowler points out in this week's short chapter from My Job Went To India.
There are two aspects to consider when building your personal brand: recognition and respect. Chad uses the swastika as the prime example of branding for awareness without positive association: almost everyone in the western world would think of Nazis when they see it (recognition), even if they have no respect for it.
On the other hand, you could also be like Minor Threat are to Blink 182, or the Ramones are to the Backstreet Boys - as Chad puts it about Charlie Wood, relatively "no recognition and lots of respect."
Ideally, you'd have lots of recognition and respect.
You can start by making sure you don't have a negative image.
Don't be a jerk, especially online. The search engines won't easily forget, which means prospective employers (and dates!) will be able to find out how often you've been an asshole. If you're near the top of those search results, you could soon be singing with Cher.
But you can go further than not being a jerk. You can show that you're taking an interst in self-improvement, that you're passionate about what you do to the point of discussing, learning, or doing it outside of work, and that while you don't know everything, you're actively filling the gaps as you encounter them.
You can gain respect.
It's easier to gain recognition by being negative or catering to the lowest common denominator than by earning the respect of your peers. That's called selling out. If you can do both, with just a modicum of success ... can you imagine the potential you have?
Stand up and tell the class, "what do you want to do with your life?"
Posted by Sam on Jun 27, 2008 at 12:00 AM UTC - 6 hrs
Linus Torvalds, Yukihiro Matsumoto, David Heinemeier Hansson, and Larry Wall. They're all famous software developers
you may have heard of. If you haven't heard of them, surely you know about some of their creations:
Linux, Ruby, Rails, and Perl.
Checking the Rails core alumni list, I had heard of half of them before I knew they were ever Rails team members.
You know other names as well - many inside what you might consider your core community, and probably several
outside of it.
Even if these developers weren't trying to do so, they
did a fantastic job of marketing themselves. As Chad Fowler notes in this week's chapter of MJWTI,
Anyone can write Struts or Nant on their
résumé. Very few can write Struts committer or Nant committer.
When thinking about marketing yourself as a programmer, keep that in mind. In other words, it's not just
about the fame from a hugely successful project you started, or the love from all the sexy kittens who
know your name.
Simply having participated in the project shows not only your passion for software
development, but also that you're well versed in the technology you intend to use. You helped develop it, after all.
My own experience in this sphere has been limited, but it's something I hope to rectify.
I have released a couple of projects, to little fanfare, but since then, I've been wanting to work on projects that someone else started, because being responsible for
the life of the project is something I'm just not interested in at the moment.
In pursuit of that goal, at the beginning of the year, I resolved to get more involved in OSS
(among other things), and for a couple of weeks I actually stuck to it. But once school started I quickly
realized that there just wasn't enough time to do everything I wanted, and open source contributions were
some of the first to go.
Another limitation was that while I wanted to work on JRuby, I wasn't using it for any major projects
(just many small scripting tasks) - so
I couldn't even help in the most obvious way of filing bug reports. However, now I'm working on a Ruby on Rails
application that we expect to deploy on .NET using IronRuby, so I may get some good opportunities to help
on that project, even if just by a little.
These are all baby steps. I expect to get more involved in the future, even if in small ways to various projects that
never lead to "committer" status.
Posted by Sam on Jul 04, 2008 at 12:00 AM UTC - 6 hrs
Seriously, be a purple cow.
Not [the] best cow or most milk-giving cow or prettiest cow. A purple
cow would stand out in a crowd of best, most milk-giving, and prettiest
cows. [Indeed,] It would be the purple one that you would talk about if you saw
-Chad Fowler in My Job Went To India, with the idea from Seth Godin (whose book is linked in the quote)
Chad illustrates the entire point in less than ten words:
Remarkable definitely doesn't mean the same thing as good.
I've never believed I'm smart or gifted or otherwise especially endowed with intelligence. To me, working hard and putting in the effort has always been the key to success. Not until many years after I came to that conclusion did I read about how "eastern" educational philosophy outpaces that of the "west" in that way.
This is hard for me to say, given those beliefs, but it's something I've come to realize in the past few weeks: it's not hard to be remarkable. Let me explain how easily not sucking leads to remarkability, from stories I've personally experienced in the last two weeks.
A Tale of Two Types Of Customer Service
Hi, I just bought a reel for my garden hose, and there's supposed to be a short 3 foot hose that connects the faucet to the reel which connects to the hose. The reel I picked up didn't have one on it, can I get one?
Sure, is there something I can "steal" and give you from another one?
Hi, I just bought a ceiling fan and installed most of it until I realized one of the blades is scratched. Do I have to disassemble the fan and bring it all back in?
No, just bring the blade and the receipt...
Marsha, check out this 61 inch slim DLP TV. Isn't it awesome
Well, the viewing angle sucks. Can't we get a flat screen LCD?
Wow. You're right.
We don't have one. The nearest one in the computer is in Corpus Christie [3.5 hours drive time], but there's also one in the warehouse that will be here Friday.
That's not good enough, I need it by Monday.
[After making some calls to check around for TVs not in the system] I located one for you. It can be here tomorrow at 1 PM.
Great, I'll see you then.
Contrast those short stories with taking Wednesday off to get telephone service, calling AT&T and asking why a technician never showed up to get told they'll be there Thursday, to be taking off all day Thursday and then calling asking why a technician never showed up to get told they'll be there Friday, to be taking off all day Friday and calling to be told there was a problem with your order and no one ever bothered to call to tell you about it, to be taking off and calling ...
Also contrast those short stories with waiting a week for an appointment with Comcast on Monday, to be calling after the time frame ended, to being told to wait up as late as you can because they have flashlights, to being told they'll certainly be there Tuesday, to waiting until Wednesday, and again until Thursday.
Aside from the monopolistic consequences we observe, the difference in customer service is striking. Normal would have been acceptable, but the first three examples were remarkable, especially given the crap that came later.
There may be a lot of companies who aren't looking for great hackers, so perhaps being one isn't going to be in your best interests for finding just any job. It may be in your interest for finding an incredible job, however.
I used to think being lazy might be a quality of a good software developer. Instead, I learned that you should be proud, not lazy. It's not the negative side of pride we should strive for, mind you - it's the the limit of not sucking x_amount as not sucking x_amount approaches infinity.
I don't want to be around people who only want to succeed. I want to be around people who want to excel.
It's that easy to be remarkable to most people. It's the difference between being the one who blows the feather that ends up floating in the wind versus being the feather.
Being remarkable is the difference between being the one to flush the toilet as opposed to being the piece of shit that rides the wave down.
As always, comments, thoughts, and criticism are encouraged and appreciated.
Posted by Sam on Jul 11, 2008 at 12:00 AM UTC - 6 hrs
Don't be afraid to make connections with other programmers, even if you might consider them a "rockstar." Those connections can make you a much better software developer.
That's the point Chad Fowler makes in this week's chapter of MJWTI.
After relating the concept to the music scene (with which at one time I was also familiar), Chad (not surprisingly) sums up the matter in a few well-chosen words:
The most serious barrier between us mortals and the people we admire is our own fear. Associating with smart, well-connected people who can teach you things or help find you work is possible the best way to improve yourself, but a lot of us are afraid to try. Being part of a tight-knit professional community is how musicians, artists, and other craftspeople have stayed strong and evolved their respective artforms for years. The gurus are the supernodes in the social and professional network. All it takes to make the connection is a little less humility.
One of the reasons I started blogging was to make connections with other programmers. I enjoy it. Before I started reaching out to my fellow code-enthusiasts, I sucked. I still suck (don't we all?), but I suck progressively less each day. Part of the reason I'm on the road to Notsuckington can be attributed to the connections I've made with all of you.
Some of you taught me better design. To argue better. To write clearly, in code and prose. The value of being a wishy-washy flip-flopper.
Some of you helped me find flaws in my own work. Some helped correct them. The list could literally continue much further. However, in the interest of not publicly proclaiming myself a leech, I'll stop there.
Boo! Are you scared? Am I a zombie who wants to feed on your brain?
Ok, so I am a zombie who wants to feed on your brain. Luckily, it's not a zero-sum proposition. You can retain your thoughts, knowledge, and memories while also sharing them with me.
Feel free to drop me a line any time. You might be able to teach me something, even if you're asking a question. I might be able to teach you something too. I won't be offended at you contacting me if you won't be offended if I don't always have the time to respond.
Let's travel to Notsuckington together.
Have you any stories of how connections with other programmers have made you better? Please, share them with the rest of us! (You can leave the names out, if you want.)
Posted by Sam on Apr 02, 2008 at 12:00 AM UTC - 6 hrs
I don't remember what I thought the first time saw the title of this
chapter ("Learn to Love Maintenance")
from My Job Went To India.
I felt sick though. The thought process probably went something like this:
Oh no. You mean I'm going to be stuck here so long I better learn to love it?
I've got it really bad - I have to maintain a bunch of the code I wrote. Mere mortals cannot
comprehend how bad that is. When do I get to toss my refuse off to some other sorry excuse for a programmer?
But Chad Fowler (in the book) turns it around, saying that not much is expected of maintenance programmers.
You just need to fix the occasional bug or add a small feature here or there. It really boils down to this:
[In a greenfield project,] when we don't have the constraints of bad legacy code and lack of funding to deal with, our managers and customers rightfully expect more from us. And, in project work, there is an expected business improvement. If we don't deliver it, we have failed. Since our companies are counting on these business improvements, they will often put tight reigns on what gets created, how, and by when. Suddenly, our creative playground starts to feel more like a military operation - our every move dictated from above.
But in maintenance mode, all we're expected to do is keep the software running smoothly
and for as little money as possible. Nobody expects anything from the maintenance
crew. Typically, if all is going well, customers will stay pretty hands-off with the daily management of the maintainers and their work. Fix bugs, implement small feature requests, and keep it
running. That's all you have to do.
Moreover, after enough code is written, that new project isn't much different than your maintenance work.
It's just missing the benefits.
Consequently, you've got a lot more freedom in maintenance to do as you will. Get creative. Spruce up the UI a little bit.
Since you get to interact with your "customer" more often,
"more people will know who you are, and
you'll have the chance to build a larger base of advocates in your business."
On top of that, being responsible for
the entire application, it's likely that "even without much effort, you will come to understand what
the application actually does." In doing so, you're well on your way to becoming a domain expert.
As I've mentioned before in several of the "Save Your Job" series' posts,
as of this writing, I'm working with a small company. So, not only am I a maintenance programmer, I'm a
greenfield project programmer too. I've been known to wear more than one hat (As I'm sure many of you can
Because of that and the push to drive maintenance costs down - I don't get as many opportunities to get
creative in maintenance as Chad suggests. That's a bit of a downer for me.
But he ends it on a motivational high note in the "Act on it!" section: Pick the most important aspect of
your maintenance work and find a way to measure it. Make it a point to improve your performance in that
area, and measure again. Continuously improve. It's more motivating than having the mindset laid out in
the introduction to this post, and you'll likely
raise a few eyebrows.
Posted by Sam on Mar 28, 2008 at 12:00 AM UTC - 6 hrs
When I work in Windows, I don't get as much done as when I'm in MacOS X.
It's not because MacOS is inherently better than Windows productivity-wise. It's because
my calendar and time-boxing mechanism resides on MacOS. So when I've got an entire day of
work to do in Windows, I don't have anything telling me "it's time to switch tasks."
Why is that a problem? That's the focus of this week's chapter in MJWTI. (Last week, I took a mini-vacation / early bachelor party to go fishing at Lake Calcasieu in Southwest Louisiana, so I didn't get around to posting then in the Save Your Job series.)
The "Eight-Hour Burn" is another of the chapters in Chad's book that really stuck with me after I first read it.
The premise is that instead of working overtime, you should limit each day's work to an 8 hour period of intense activity. In doing so, you'll get more done than you otherwise would. Our
brains don't function at as high a level as possible when we're tired. And when we're working
on our fifth 60-hour week, we're probably tired.
We may love to brag about how productive we are with our all-nighters [paraphrasing Chad], but the reality is we can't be effective working too many hours over a long period of time.
And it's more than just our brains being tired that should prevent us from working too long. It's the fact that when we know we've got so much extra time to do something, we end up goofing off anyway:
Think about day 4 of the last 70-hour week you worked. No doubt, you were putting in a valiant effort. But, by day 4, you start to get lax with your time. It's 10:30 AM, and I know I'm going to be here for hours after everyone else goes home. I think I'll check out the latest technology news for a while. When you have too much time to work, your work time reduces significantly in value. If you have 70 hours available, each hour is less precious to you than when you have 40 hours available.
That's why I'm in trouble when I work in Windows all day. I do work 12-16 hours most days between job, school, and personal activity (like this blog). I get burnt out every few weeks and have to take a couple of days off, but when I'm in MacOS X, at least my working days are very productive: I've got each task time-boxed and any time I spend reading blogs or news or just getting lost on the web is always scheduled.
When I'm in Windows with nothing to remind me but myself, I drift off quite a bit more easily. After all, it's only 6:30 in the morning. I've still got eight hours to get everything done (I'm leaving early to go check the progress on the house I'm having built).
The good news is that I've got an item on my longer-term to-do list to remedy the situation. Hopefully after reading this chapter again, I'll be more motivated to get it done. The bad
news is, since it means working in Windows all day to get it done, I'll probably be off
doing my best to read all of Wikipedia instead.
Anyway, how much do you work? Do you have any tricks for staying fresh and motivated?
Today we'll start looking at the "Maintaining Your Edge" section of the book.
Chad starts off by explaining what can happen if you get too comfortable: Tiffany.
Not that Tiffany, this one:
Do you remember a pop star named Tiffany (no last name) from the 1980s? She was in the top of the top forty, and a constant sound on the radio back then. She enjoyed immense success, becoming for a short time a household name.
Apparently, if she tried, she didn't move fast enough to hold the affection -- or even the attention -- of her fans. When the tastes of the nation turned from bubble gum to grunge, Tiffany suddenly became obsolete.
The point remains: you need to stay sharp. You cannot sit back and become complacent. Doing so in this industry can cause you to become extinct. And you'll probably be less famous than Tiffany or the Dodo. However, Didus ineptus may end up describing you well.
One thing you can do to stay sharp is recognize that, relative to information growth, your knowledge and skill levels are deteriorating rapidly. The consequences of what Gordon Moore observed in 1965 is that new possibilities for computation arise at an astounding rate.
That graph looks linear, so what's the big deal? Look at the left - it's logarithmic scale. That graph really looks like this:
That slope is so high it's almost negative.
You can't keep up with everything - but you can't afford to be late to the party when it comes to new trends in development either. If you were a desktop application programmer in 1992 and didn't look up until 2002, you'd probably say a few WTFs, and then start drowing in all the information you'd need to get started programming web applications. There's a lot to learn in new paradigms.
So you need to anticipate changes. You might not be able to jump the gun on the next big thing, but at worst you'll have augmented your arsenal, and you can stay close to other trends as well. Reading blogs and staying current in news and even journals can help you find new, up and coming developments. Thinking about how things will change and backing your hypotheses up with evidence from the literature can be a worthwhile activity in that regard.
Looking ahead and being explicit about your skill development can mean the difference between being blind or being visionary.
Know that you'll be obsolete. Don't accept obsolescence.
How do you deal with the pressure to stay current? What new things are you learning?
Posted by Sam on Aug 01, 2008 at 12:00 AM UTC - 6 hrs
Making goals and achieving them - overcoming adversity to gain something you want - is tremendously motivating and often rewarding in life. Still, there are often times you extend so much effort in focusing on the goal that you don't notice the journey, or worse: you make the journey downright unpleasant.
The point revolves around the fact that hitting the goal is short-lived, while the process of getting there takes up the bulk of the time. Therefore, wouldn't it be better to view the process as the goal itself, and make that the enjoyable part?
My view diverges from Chad's here. Whereas he implies that this observation is a better way to live generally, I tend to think it applies to particular people doing particular things. For instance, I might agree that, in general, the US is "a nation of people who are always focused on the outcome of a process," I wouldn't agree that it's "one of America's biggest problems" (Quoting Chad Fowler, pg. 156). Still, I might be more inclined to think that people's choice of goals doesn't line up with my own.
Regardless of the small divergence of our beliefs about the theory in general, I do agree that it works for software development. I'm not talking about doing software development as a means to achieve fame, fortune, girls, and cars (or just as a means to do something else with your life). For the production of software as a means to reach goals (including some where the path is the goal), I agree with Zed Shaw:
I've been saying for years that you can live a life involving code and hacking as a cultural phenomenon, but you can't live a life that only has code. You can work and make money doing web programming, but you can't make a life out if it. I try fill my mind and experiences with other shit, and then use code as one of many ways to express myself.
Those kinds of goals are rewarding long after you've achieved them. Memories last until you forget them, and you can drive that Ferrari convertible up and down the Pacific Coast Highway until it falls apart.
But if you're talking about finishing a project as the goal, then you're likely to put yourself in a lot of pain during the journey.
Back to the software development example, it's easy to get wrapped up
in the delivery of the code you are creating. Your customer needs a web
application up, and you focus on finishing that application. But, a living
application is never "done." One release leads to the next. Too much focus
on the end product distracts us from the real deliverable: the sustainable
development of a new entity.
Focusing on the ending makes you forget to
make the process good. And, bad processes
create bad products. The product might meet
its minimum requirements, but its insides will
be ugly. You've optimized for the short-term end goal -- not for the
inevitable, ongoing, future of the product's development.
Not only do bad processes make bad products, but bad products make bad
processes. Once you have one of these products that is messy inside, your
processes adapt around it. Your product's broken windows lead to broken
windows in your process. It's a vicious cycle.
It does to me. A focus on a ridiculously short promised delivery date leads to no tests leads to coupled code modules and "quick and dirty" hacks in the code. That leads to an inability to test and more hacks in maintenance. And the cycle continues.
Wouldn't it be better to treat the process of making applications as the goal to be enjoyed, rather than masochistically torturing yourself?
What's your experience like? Are you more likely to treat the end as the goal or the path? Which works better for you?
To be fair, it may be more enjoyable, but it might not be as profitable - at least that's what Chad Fowler talks about in this week's chapter from My Job Went to India, "Make Yourself a Map."
Staying sharp is hard to do. It's easy to get into "maintenance mode," becoming comfortable with where you're at, and staying there. While maintaining your health may be a fine thing to do, simply maintaining your current skill set means you'll become the next Javasaurus. By that I don't mean you'll be big, bloated, and intimidating. I mean when all you know is Java the language, and Java's no longer the language du jour, you'll go the way of the dinosaur (to borrow an often used cliché). When it comes to technological matters, you fall behind if you're not actively keeping up.
Your personal product road map is what you use to tell whether you've
moved. When you're going to the same office day in and day out, working
on a lot of the same things, the scenery around you doesn't change. You
need to throw out some markers that you can see in the distance, so you'll
know that you've actually moved when you get to them. Your product
"features" are these markers.
Unless you really lay it out and make a plan, you won't be able to see
beyond the next blip on the horizon. In Chapters 2 and 3, you discovered
how to be intentional about your choice of career path and how to invest
in our professional selves. Though I focused on what seemed like a onetime
choice of what to invest in, each choice should be part of a greater
whole. Thinking of each new set of knowledge or capability as equivalent
to a single feature in an application puts it in context really well. An
application with one feature isn't much of an application.
What's more, an application with a bunch of features that aren't cohesive
is going to confuse its users... A personal product road map can not only
help you stay on track, constantly evolving, but it can also show you the
bigger picture of what you have to offer...
While it's definitely OK to learn diverse skills -- it expands your thinking --
it's also a good idea to think about the story your skill set tells. (Bold emphasis applied by me.)
For a couple of vacations I've taken in the past, I spun a pen on a map and drove to where it pointed the same night (up to 15 hours away). So far, my career map looks the same: as if a monkey tossed darts at a bunch of options and I decided to follow whatever the darts landed on.
I'm mostly a web developer - in the sense that I derive most of my income, write most of my code, and spend most of my time writing code that will in some way show up on the web or affect something that will show up on the web.
AI and game development dovetail nicely with each other. There are a lot of similarities between and overlap in algorithms for bioinformatics and AI. But short of creating a bioinformatics game on the web, it's hard to imagine where all these skills and interests intersect.
Perhaps it would be better for me to try and create a coherent picture out of the skills I choose to learn. But I rather enjoy having my hands and mind roam freely.
How's your skill set? Is it too focused, where you might need some breadth, or do you have a bit of a programmer dissociative identity, where some cohesion could take you a long way?
Posted by Sam on Aug 15, 2008 at 12:00 AM UTC - 6 hrs
The concept is simple economics: supply and demand. Ideally, you'd like to be a developer with skills that are high in demand, where there isn't yet much supply. That gets you jobs, and higher paying ones at that.
The theme in this part of Chad Fowler's MJWTI is reiterated here: don't rest on your laurels. You have to be proactive about keeping your skills up-to-date. Paying attention to the market, and acting on the knowledge that's available regarding the "in" technologies will help you do that.
Chad tells a hypothetical story about the demise of Java:
What if, for example, Sun Microsystems started showing signs of going
under? Java isn't an open standard. It is dictated and developed by Sun.
At any point, a dying Sun might attempt to suddenly make its language
and virtual machine into a last-minute profit center. They might introduce
incompatible changes or suddenly change the license restrictions of Java,
causing an industry panic followed by a mass exodus.
With your head in your monitor coding, you might not even hear about
something like this until it was too late.
What if you're a Flash guru and Microsoft's Silverlight comes pre-installed on 98% of the computers in the world as Adobe's Flash loses the support of management? Will Flash maintain it's market share? What if Adobe drops support for ColdFusion? Will the open source world carry the torch? What if Microsoft decided .NET isn't going to cut it for the next generation of programming paradigms, and scraps it? Will your skills in .NET be valuable for as long as your career keeps you working? What if management decides they want to standardize on a cross-virtual-machine dynamic functional language called Fan, and they want to keep the familiar curly-brace-and-semi-colon syntax? Will you still be using Ruby, Python, or Perl at your day job?
Are you willing to take those chances?
The most likely scenario is that these technologies will continue to exist, as they slowly fade away into the Next Big Things. As Chad notes,
Even more likely is that, comfortable in your current job with your current
set of skills, you might remain blissfully ignorant of the Next Big Thing as
it rolls in. Ten years ago, you would have been surprised to find out just
how big object-oriented languages with garbage collection would become.
But, there were definitely signs if you were watching.
Ten years ago we couldn't have done the work with DNA and large genomes that we can do today. More interesting problems (in bioinformatics and elsewhere) are able to be solved by more people just because of increases in memory, processor speed, disk space, and number of processors. What are you doing to learn about concurrency? What are you doing to learn about optimizations you can make? When constant-factor reductions in processing time save days to weeks of computations, it's not premature to make them.
Posted by Sam on Aug 22, 2008 at 12:00 AM UTC - 6 hrs
Some people call them fat pants. Some people call them stretch pants. Others might call them exercise pants or sweat pants. Whatever you call them, they're comfortable to wear. The problem with sweat pants is the reason they're comfortable is because they're big and expandable. And that expandability means they have a lot of room to accommodate growth as well.
In fact, some people wear them when they know they'll be eating a lot, just for that purpose.
It's hard enough to know when you're getting fat - after all, you're you and it's a slow process, so you wouldn't notice unless your pants got tighter or you were reviewing your weight on the scale regularly.
It's even harder to notice when you're wearing sweatpants. You can go for years - growing and growing ...
And before you know it, you've not just beat anorexia, you've pwned it.
As with the other chapters in this section of My Job Went To India, "That Fat Man in the Mirror" boils down to refusing to let yourself become comfortable in where you're at personally (not geographically) as a programmer. In this case, you need to put away your programming skill fatpants, and periodically review your skills. Take an inventory. Better yet, have someone else evaluate you. Sweats may allow for growth, but it's not the good kind.
An easy way to measure your progress is to use a trusted third party. A
mentor or a close colleague doesn't live in your head with you and can
help give you a more objective look at where you stand. You might discuss
your abilities as a software developer, project leader, communicator, team
member, or any other facet of the total package that makes you who you
are. (Chad Fowler, pgs. 155-156 of My Job Went to India)
If you're a bit uncomfortable asking someone to help in that way, you should make
use of review-time at your company (if there's such a thing where you're at).
If your company has such processes in place already, don't write them off
as HR nonsense. Take them seriously and make good come out of them.
Keep it written down and revise and review often, Chad says.
That sounds like solid advice to me. I got started with some goals earlier in the year, and had planned to periodically review them here on the weblog. But that hasn't happened, so it's something which I need to put more effort into.
Don't get be lethargic about your skills. Instead, take off the fatpants and actively evaluate where you're at and where you need to be. Get some feedback. Otherwise, some day in the future you may end up wondering to yourself, "how did I lose my edge?"
Do you review yourself periodically? Have you used the reviews to become better?
Posted by Sam on Aug 29, 2008 at 12:00 AM UTC - 6 hrs
If you want to trap a monkey, it's not very hard. Hollow out a hole (in a coconut, the ground, or whatever)
just large enough for a monkey's hand to fit in when relaxed, but too small to pull out as a fist.
Put some food in the hole, and wait. Soon enough, a monkey will come, fall in love with the food, grab at it
and refuse to let go.
You see, monkeys value food higher than life or freedom, and their devotion to it will not allow them to let
go. Or so the story of the south Indian monkey trap goes.
(I am merely relating the parable, I have not actually tried to capture a monkey in this manner.)
In My Job Went to India, Chad Fowler's final bit of advice for keeping sharp and
up to date urges us to not allow ourselves the mental security blanket of value rigidity - or the mental crutch,
as it often turns out to be. You might not even be aware you're using one yet.
Chad tells the story of Novell's decline:
Many of us in the mid-1990s swore by Novell's NetWare platform when it
came to providing ?le and print services in the enterprise. Novell was way
ahead of its time with its directory services product, and those of us "in
the know" were almost cocky in our criticism of competing technologies.
Novell's product was enjoying a healthy majority in market share, and it
was hard to imagine the tide turning.
No single event made it obvious that Novell was losing to Microsoft.
Microsoft never made that magic Active Directory release that made us all
say, "Wow! Drop NetWare!" But, Netware has slowly gone from bleeding-
edge innovator to legacy technology. For many NetWare administrators,
the water was boiling before they ever even realized the pot was warm.
By allowing yourself the comfort and ease of such a mental crutch, you're doomed to keep repeating what worked in the past, even if it's not the best solution today. Before you know it, your technology of choice is no longer the soup du jour, and you're stuck knowing nothing else.
Instead of blindly advocating your technology of choice -- no matter the absurdity of that solution in the
situation -- have "stong opinions which are weakly held."
Realize "it depends" is a valid answer to programming questions.
Posted by Sam on Sep 04, 2008 at 12:00 AM UTC - 6 hrs
Outsourcing is not going away. You can delude yourself with myths of poor quality
and miscommunication all you want, but the fact remains that people are solving
those problems and making outsourcing work.
As Chad Fowler points out in
the intro to the section of MJWTI titled "If You Can't Beat 'Em", when a
company decides to outsource - it's often a strategic decision after much deliberation.
Few companies (at least responsible ones) would choose to outsource by the seat of their pants, and then change their
minds later. (It may be the case that we'll see some reversal, and then more, and then less, ... , until an equilibrium is reached - this is still new territory for most people, I would think.)
Chad explains the situation where he was sent to India to help improve the offshore team there:
If [the American team members] were so good, and the Indian team was so "green," why the hell
couldn't they make the Indian team better? Why was it that, even with me
in India helping, the U.S.-based software architects weren't making a dent
in the collective skill level of the software developers in Bangalore?
The answer was obvious. They didn't want to. As much as they professed
to want our software development practices to be sound, our code to be
great, and our people to be stars, they didn't lift a finger to make it so.
These people's jobs weren't at risk. They were just resentful. They were
holding out, waiting for the day they could say "I told you so," then come
in and pick up after management's mess-making offshore excursions.
But that day didn't come. And it won't.
The world is becoming more "interconnected," and information and talent crosses borders easier than it has in the past.
And it's not something unique to information technologists - though it may be the easiest to pull-off in that realm.
So while you lament that people are losing their jobs to cheap labor and then demand higher minimum wages, also keep in mind that you should be trying to do something about it. You're not going to reverse the outsourcing trend with
any more success than record companies and movie studios are going to have stopping peer-to-peer file sharing.
That's right. In the fight over outsourcing, you, the high-paid programmer, are the big bad RIAA and those participating in the outsourcing are the Napsters. They may have succeeded in shutting down Napster, but in the fight against the idea of Napster, they've had as much strategic success as the War on Drugs (that is to say, very little, if any). Instead of fighting it, you need to find a way to accept it and profit from it - or at least work within the new parameters.
How can you work within the new parameters? One way is to "Manage 'Em." Chad describes several characteristics that you need to have to be successful with an offshore development team, which culminates in a "new kind" of
What I've just described is a project manager. But it's a new kind of project
manager with a new set of skills. It's a project manager who must act at
a different level of intensity than the project managers of the past. This
project manager needs to have strong organizational, functional, and technical
skills to be successful. This project manager, unlike those on most
onsite projects, is an absolutely essential role for the success of an offshore-developed
This project manager possesses a set of skills and innate abilities that are
hard to come by and are in increasingly high demand.
It could be you.
Will it be?
Chad suggests learning to write "clear, complete functional and technical specifications," and knowing how to write use cases and use UML. These sorts of things aren't flavor-of-the-month with Agile Development, but in this context, Agile is going to be hard to implement "by the book."
Anyway, I'm interested in your thoughts on outsourcing, any insecurities you feel about it, and what you plan to do about them (if anything). (This is open invitation for outsourcers and outsourcees too!) You're of course welcome to say whatever else is on you mind.
To do that, you need to overcome challenges associated
with non-colocated teams that exceed those experienced by teams who work in the same geographic location.
Chad lists a few of them in this week's advice from
My Job Went To India (I'm not quoting):
Communication bandwidth is lower when it's not face to face. Most will be done through email,
so most of it will suck comparatively.
Being in (often widely) different time zones means synchronous communication is limited to few overlapping
hours of work. If you get stuck and need an answer, you stay stuck until you're in one of those overlaps.
Language and cultural barriers contribute to dysfunctional communication. You might need an accent to accent
translator to desuckify things.
Because of poor communication, we could find ourselves in situations where we don't know what each other
is doing. That leads to duplicative work in some cases, and undone work in others. Which leads to
more sucking for your team.
The bad news is that there's a lot of potential to suck. The good news is there's already a model
for successful and unsuccessful geographically distributed projects: those of open source.
You can learn in the trenches by participating. You can find others' viewpoints on successes and
failures by asking them directly, or by reviewing
open source project case studies.
Try to think about the differences and be creative with ways to address them.
Doing that means you'll be better equipped to cope with challenges inherent
with outsourced development. And it puts you miles ahead of your bitchenmoaning colleagues who end
up trying to subvert the outsourcing model.
Posted by Sam on Sep 19, 2008 at 12:00 AM UTC - 6 hrs
Chad Fowler describes the problem:
What I've noticed since coming back from India is that in America we are
so focused on ourselves that we don't even take the time to learn about our
teammates from other parts of the United States. What's the special food in
Minnesota? What do Arizonans do on the weekends in their nonexistent
winters? The United States is a diverse place, and we don't even bother to
learn about our own diverse culture, much less the cultures of people on
I don't want to get into the merits of whether or not Americans are inward-looking and selfish. The
important part here is that as the world becomes smaller, nation-states are losing importance as
cultural and political boundaries, and we're increasingly exposed (and exposing ourselves to) new
people from unfamiliar places. We can choose to embrace this, or fight it.
If I have to depend on someone to get something
done for me or to deliver a piece of software that I have to successfully
integrate with, I'm going to have much better luck if that person feels I
respect them and if they respect me. Would you respect someone who
wouldn't even bother to learn how to pronounce your name?
If you show your teammates that
you are interested in them as people, you will form tighter bonds and, on
the whole, do better work.
On the contrary, you could be an ass - perhaps without even realizing it:
As I got to know our team members in India, I often heard them say that I
wasn't like the typical American manager. When I asked what they meant,
those who felt comfortable enough would say, You actually take an interest
in us. Most of you are just angry and short with us.
I had a fellow student at school say the same thing to me. He asked, "Are you natively American?" It was
eye opening to think that he had been treated so poorly by other Americans that he had to ask me if I am one
Incidentally, this is a tactic in getting anyone to like you generally, so if you have friends, you don't
need to learn any new skills. In this case, it may be even easier because you know
tons of things exist that you don't know about them: just pick a couple and ask about them. All Chad
had to do was say "Hello, my name is Chad" in their native language.
It's about making a small effort, that's all.
This week marks the end of the Save Your Job series,
at least as far as following each chapter of Chad Fowler's book, My Job Went To India.
Why? Well, because it's the last one in the book. I'll still post to that category as things come up,
but it's not likely to be weekly.
This is a book that, in my opinion, is a must-read for software developers, and it's so short you can read it
multiple times - to remind yourself as you slip back into old habits, or to reinvigorate interest in goals
you set for yourself in times past.
In any case, I hope you've enjoyed the weekly series, and more than anything else, I hope you got something
useful from it. It was useful to me!
While I thoroughly enjoyed Chad's book, I must say I'm glad to be done with the series. I've been wanting
to free up some time to do some more technical things, like playing with my new Arduino Diecimila.
Posted by Sam on Mar 05, 2010 at 10:14 PM UTC - 6 hrs
You might think that "tech support" is a solved problem. You're probably right. Someone has solved it
and written down The General Procedures For Troubleshooting and How To Give Good Tech Support.
However, surprisingly enough, not everyone has learned these lessons.
And if the manual exists, I can't seem to find it so I can RTFthing.
The titles of the two unheard of holy books I mentioned above might seem at first glance to be
different tales. After all, troubleshooting is a broad topic applicable to any kind of
problem-solving from chemistry to mechanical engineering to computer and biological science.
Tech support is the lowliest of Lowly Worms for top-of-the-food-chain programmers.
(And don't ask me how sad it makes me feel that my favorite book as a kid has only a 240px image online. I need to find my copy and scan it.)
But just like its more enlightened brethren, tech support consists of troubleshooting. In fact, it should be
the first line of defense to keep your coders coding and off the phone. Who wants them to man the phones?
Certainly not the programmers. Certainly not management. Tech support is a cost center, not a customer
Perhaps when you have a virtual monopoly over a market like most cable companies or utilities in a given locale,
you can afford to have poor customer service. The cable sphere seems to be opening up, what with satellite TV and internet
and now AT&T and Verizon offering television and decent-to-good internet packages.
Even still, AT&T's UVerse has its own problems, I've heard,
and (at least personally) I've not witnessed the kind of customer service that competition promises with regards to cable TV and internet access.
The fact is we tend to treat support like a second class citizen. It's a position we want to fill with a minimum-wage worker (or less, if we
can outsource it) who has no expertise, no clue, and doesn't care to learn the
product since he can get a job in the fast food industry at about the same rate. And with no stress!
It makes it worse that we don't even want to take the time to train him, since it would take away from the productive code-writing time to do so.
The person we want to treat as an ape or worse always seems expendable. We treat them so. Should they be?
I don't think it needs to be a full-time thing, but it certainly helps if programmers are their own support team.
Like Bruce Johnson who posted that linked message, I work on a small team and can vouch: it's downright embarrassing to have to support
our customers. I'm glad to do it, but when it happens, more than likely I've got to take blame for the problem I'm dealing with.
You know how hard I try to make sure my code works as expected before I deploy it?
"OMG I'm sorry, that's my fault, I'll fix it for you right away." Can you get better support than that?
I'm not so sure I'd have tried that hard without the customer experience pushing me.
I think I've made my first point: that customer support is customer service is important to the health of your business.
While I agree that tech support in the common use of the term is useful to shield your programmers from
inane requests, I also recognize the value in having programmers take those calls from time-to-time.
Given that, I do in fact have some do's and do-not's with regards to support. The list here deals mostly with
how to be a good support technician for your team, as opposed to the customer. Still, the customer is
central to the theory.
Although it does not make an exhaustive list, here are four contributions to The General Procedures For Troubleshooting:
After listening to the problem description, the first thing to do is recognize whether or not you can
solve the problem while the customer is on the phone, or if anyone can. If you can, then do it. If you think
only someone else can do it, and work for an organization that has multiple levels of live-support, then escalate it.
If you don't think solving the problem is possible without escalating it to a level of support that won't get
to it immediately, thank the customer for reporting the issue, let them know the problem is being worked on,
and boogie on to step 2.
As support, the first thing you need to do before escalating the issue is confirm there is an issue, and do it with a test account, not the user's.
It's ridiculous to ask for the user's
credentials. Don't do it. If someone were to ask you, "What is your username and password?" what would you think?
The average user isn't going to know your query is tantamount stupidity, but if you get someone who is slightly
security-conscious, you're going to lose a customer. Hopefully, he's not a representative of your
If anyone found out that you're in the habit of asking users for their passwords, they can easily call anyone
who uses your software and get in by just asking. Further, since many people use the same password for everything
or many things, that person would also have access to your customers' other sensitive information, wherever it resides.
You can point the blame at your stupid customer for using the same password everywhere they go all you want. You're being
just as stupid by opening the door for that type of attack. Further, you should always try to recreate and fix the problem
with as little inconvenience to the user as possible. That means doing it with test accounts as opposed to asking the
user for theirs, or changing their information.
Keep things simple for the user. Don't jump immediately to using their time to make things easier on the support team.
Doing that is lazy at best, sloppy most of the time, and could result in disaster at worst.
After confirming the existence of the problem, provide the steps of how to reproduce it. Give some screen shots.
If it's a web app, provide links. Don't constantly send and email and ask the higher levels about it. Doing so once or twice is
one thing, but doing it for every request is a time-waster. Just send the email and the next level will get to it
when they can. If they don't get to it within the acceptable time-frame for your organization, send a reminder.
Include the boss if you need to. But don't do that prematurely (and that's another subject altogether).
Don't jump to conclusions about the source of the problem.
Although Abby Fichtner wasn't speaking
directly to support ...
... This is the opposite of my general approach. The parallel here is code : customer :: you : dumb2.
I've learned (even if through a bit of self-torture) that I should always look at the code first, if for no other reason than I don't
want to be foolishly blaming others when I'm to blame. In the case of support, I've always hated the term "User Error,"
and that's what the tweet reminds me of.
By framing it as an external problem, we miss an opportunity to teach the user how to use the product, or a chance to
improve the product to make sure they can't use it "incorrectly."
What are your thoughts about tech support? What can you contribute to The General Procedures For Troubleshooting?
Posted by Sam on Dec 12, 2008 at 12:00 AM UTC - 6 hrs
This is the "z0mg it's Christmastime and have I really left so many of my goals for the year incomplete?!" edition of Programming Quotables.
If you don't know - I don't like to have too many microposts on this blog (me on twitter for that), so save them up as I run across them, and every once in a while I'll post a few of them. The idea is to post quotes about programming that have one or more of the
I find funny
I find asinine
I find insightfully true
And stand on their own, with little to no comment needed
It's up to you decide which category they fall in, if you care to. Anyway, here we go:
My first job primarily used Cold Fusion. When I joined AOL Time Warner I gave up Cold Fusion for PHP. When I joined IAG I gave up PHP for C#. And so on. As you can see, I've never been too tied to a language. I've always been most interested in learning and growing. I love jobs that help me improve my skills.
I prefer jobs that allow me to learn new things. Think of it as job security -- I shouldn't ever be out-of-date when it comes to technology experience. Think of it as an investment -- everything I learn creates a broader range of experience that I can leverage for future projects or jobs. Think of it as experimenting -- by trying many different solutions I may find ways to combine them and innovate.
Programming in C for the first time seems to be a chore. There are many details about your Code you need to keep track of. And C doesn't even lend you much of a hand when programming. There are no iterators, memory management is done manually, and handling strings correctly is akin to walking through a minefield with a hood over your head. While on fire. And being chased by a pack of wild dogs.
But then the question still stays: "what should one learn next?". Algorithms, data structures, complexity, math... Learn the core abstracts, ideas, and skills that are language independent, and that transfer from one syntax to another. Learn the ability to learn. When a new opportunity with new technology comes along, you should be able to get over the learning curve fairly quickly.
So lets drop this obsession with learning to say "hello world" (or some more complicated version of essentially the same) in every programming language one can name. Lets also drop the idea of finding "one language to rule them all; and retire". Once we put the Science back in Computer Science, it wouldn't matter which language you'll end up using.
(A disclaimer for you: I read this book as a reviewer and haven't yet made the time to go through the finished
product, so some of what I'm about to say may change. That said, I can only imagine that it got better before
going to publication, so I don't expect anyone would be disappointed.)
The Passionate Programmer retains that status of being a must-read. It adds a few new chapters and
removes a couple of others, but more importantly it changes the framing from the negative view of "save your job"
to what My Job Went to India was always really about anyway: "creating a remarkable career in software
Here's what I had to say about it for the blurb:
Six short months before I read Chad's book, I was on the verge of
changing careers. Through a series of accidents from November to
May, I decided not only to stick with software development but to be
passionate about it while striving to be great. With a healthy dose of
inspiration, the book you're now holding served as a road map for
achieving those goals.
It truly is an excellent map that helped me find my way from Quit Town to making the decision to be
passionate about hacking and life in general, starting this blog, and striving to leave the realm
of the unclean masses in our profession whose exploits we read about so often.
If you read MJWTI and understood the positive aspects of it, this book isn't that important since
you know most of it already.
I'd have purchased it anyway, but you may feel differently. That's Okay.
However, if you felt you'd be embarrassed if someone saw you holding the first version - or just
haven't read it before - I strongly recommend picking up a copy of this version and
going through it. Don't just read it though - apply it. At the end of every chunk of advice there is a list
of activities that you can perform. Don't just gloss over them; make it a point to actually do some of them.
It's short enough to read through in one or two sittings. But there's enough content in there to keep you busy for
a couple of years.
If you've read this book or the 1st edition, what did you think about it? Am I overenthusiastic?
I look forward to covering the new chapters as time allows over the next few weeks. I hope you'll join me in
Posted by Sam on Feb 15, 2008 at 08:22 AM UTC - 6 hrs
This week's advice from MJWTI
deals with making the "boring" tasks in software development more exciting (in the chapter,
"How Good A Job Can I Do Today?")
Chad notes that although "it's rewarding to do a good job and to be appreciated," most time, "we
allow ourselves to be extremely selective about where and when we really go out of our way to
So, if the Pareto principle applies
here, how can we make the 80% boring work be more like the exciting 20%, and go all out, doing our best?
Chad suggests making it a competition with yourself:
What if you tried to do the boring stuff perfectly?
Or, if you want to get competitive with your teammates,
Turn those boring tasks into a competition with your co-workers. See who can do them
better... Keep a scoreboard for the whole team. Compete for bragging rights (or even prizes).
At the end of a project, arrange for the winner to have his or her grunt work done
by the rest of the team for a whole week.
Posted by Sam on Feb 08, 2008 at 04:35 PM UTC - 6 hrs
In this chapter (Be Where You're At) of My Job Went to India
Chad Fowler warns us to "be ambitious, but don't wear it on your sleeve."
He tells us about his pet peeve as a manager: the "employee who's always aiming for the next rung on the ladder."
Aside from the annoyances of playing office politics, complaining "about the incompetence of The Management,"
and being a general jackass, there's also the way he looks at his daily duties:
He thinks many tasks are beneath him. He avoids them when possible and
does them begrudgingly (and slowly) when not. He cherry-picks work
that he thinks, even if subconciously, is in tune with his level and might
get him closer to his goal of the next promotion.
That's the paragraph that hit home with me, because I used to be that developer. However, I never
looked at it as a way to get ahead (being in such a small company and all). But, I did justify it by
saying things to myself like "this is beneath my skill level - I don't want to
waste money they are paying me by wasting time on these mundane tasks that could be done
by a monkey."
Even until recently, I took this attitude in some regard. So much so, that during our recent
SWOT analysis, I
brought it up as a weakness against myself, and resolved to take the opposite approach.
Now, I find ways to automate many
of those menial tasks, and in general just do what the job requires, without regard to the
prestige of task at hand.
If you want me to follow an elephant around with a shovel, I'll do it, and I'll try to be
the best damn shit-shoveler you've ever seen.
Posted by Sam on Feb 01, 2008 at 07:59 AM UTC - 6 hrs
This week's advice from Chad Fowler's book, My Job Went To India
tells us to "remember who you work for" when doing your job.
Chad acknowledges that saying "make sure your goals and your work align with the goals of your business" is
an easy task that's hard to accomplish. It's hard because working in IT for a major corporation, it's not
always clear what those goals are and how you and your department fit into the overall scheme of things.
To remedy this, Chad says it's easy to ask your manager how you can help. When you help your manager, he
helps his, and so on, all the way up the food chain. In doing that, you can be sure that your work is
aligned with the goals of the business, and it doesn't hurt to keep the man happy "who holds the keys to your
career (in your present company, at least)."
Of all the chapters thus far in the book, this was the least inspirational for me. That's not any fault of
Chad's but more because of the fact that I've always worked at small companies. Therefore, I've
always been fortunate enough to have close relationships with the people in power positions, and I've been much
more of a mind reader
because of it.
However, that doesn't mean I still can't ask what I can do to help us reach our goals, and what those goals
are. So earlier this week, after reading the chapter, I was inspired to do just that. Try it out and
see if it works for you, especially if you're at a larger company. Perhaps you can
discuss longer term objectives over lunch.
You've got a related story? I'd love to hear about it in the comments below.
I think you have a great concept going. I really would like to find out HOW you became passionate about programming? I just graduated with a BS in CIS and am looking for an entry level IT job, HOWEVER I am not a bit excited about computers anymore. Like you I was just planning on continuing my education -get my MBA. But I know an IT job is what I went to school for. HELP! How do I get excited about an IT job when I can't even figure out what title to put on a job search? just degree in CIS?!
I started to comment, but as it became longer, I decided it might benefit others as a standalone post.
I think you just have to make the decision to be passionate. Wake up in the morning and think about how lucky you are. Decide to enjoy the day, and to enjoy what you do. But you can do better.
Think about what drew you to the profession in the first place, and try to get a job doing that. If you can't get one in a timely fashion, try to get a job doing something similar and spend your free time working on side projects that interest you. That's a lot of what I'm doing.
For me, it is learning new things and gaming that I enjoy most. So, I spend a lot of time doing that. I still have to do grunt work, but I get equal doses of fun stuff too - all the while I am expanding my skill set and enjoying most of it.
As far as the job search goes, I'd recommend networking with people. Visit the local User Groups, get involved in forums and mailing lists. Learn things and share them, and people will eventually come to you with jobs. Even though I like the computers, I've found that I really enjoy the relationships with people who also like computers. Before, I stayed locked in a room thinking and working by myself. Now, I venture out from time to time, and in addition, I have the online relationships I enjoy immensely.
Since you probably can't afford to live that long without a job, perhaps in the mean time you can go to a career fair at a local university or just use the search term "programming" and browse jobs until you find one that interests you.
I'd also read many different weblogs about programming to stay up to date on trends in the industry, as well as to receive solid advice that stands the test of time.
Just as importantly, take a look back at your own situation. Can you identify anything that may be causing your malaise? If so, can you remove it? It may be as simple as that.
To the rest of you: how do you maintain and find passion in your work when you seem to have lost it?
Posted by Sam on Jan 18, 2008 at 09:05 AM UTC - 6 hrs
You feel, look, and do better when you are accomplishing goals and showing progress. That's one
reason you'll find it in this week's advice from MJWTI.
The chapter is called "Daily Hit" and in it Chad recommends "setting a goal (daily, weekly, or
whatever you're capable of) and tracking this type of accomplishment." Make sure it's known to
your manager as well - don't let the underpants gnomes take credit for your
success. Also, the shorter the distance between hits the better, since "if you're supposed to produce a
hit per day, you can't spend two weeks tracking the perfect task."
I work in an environment where it wouldn't benefit me to "tell the manager" about my daily hits.
They know already. But you might want to make yours known. Obviously you don't want to
be braggadocious about it, but don't keep it to yourself either.
I like to do more than one hit per day. One is the absolute minimum. I try to get an overview
of what needs to be done during the week, and create a high level plan in my mind over the weekend.
I'll set each day's tasks and the time I'll be working on them on the day before. Then, I stick
to the plan.
Even when I don't finish a task in the time allotted, I can reschedule and finish it the next day. In this way, I'm always
having small successes which keeps me motivated and moving along towards my goals.
We're not talking about just what has to be done - it's about going above and beyond that. Chad ends the chapter with the advice to make a list of the "nitpicky problems" you and your team face that waste a little time each day, and starting to do some work on those things. I've done some of that, but there's plenty left to do, and re-reading this chapter reminded me that I need to start scheduling those things as well.
Posted by Sam on Jan 14, 2008 at 06:42 AM UTC - 6 hrs
This is a story about my journey as a programmer, the major highs and lows I've had along the way, and
how this post came to be. It's not about how ecstasy made me a better programmer, so I apologize if that's why you came.
In any case, we'll start at the end, jump to
the beginning, and move along back to today. It's long, but I hope the read is as rewarding as the write.
The experiences discussed herein were valuable in their own right, but the challenge itself is rewarding
as well. How often do we pause to reflect on what we've learned, and more importantly, how it has changed
us? Because of that, I recommend you perform the exercise as well.
I freely admit that some of this isn't necessarily caused by my experiences with the language alone - but
instead shaped by the languages and my experiences surrounding the times.
One last bit of administrata: Some of these memories are over a decade old, and therefore may bleed together
and/or be unfactual. Please forgive the minor errors due to memory loss.
Before I was 10, I had a notepad with designs for my as-yet-unreleased blockbuster of a side-scrolling game that would run on
my very own Super Sanola game console (I had the shell designed, not the electronics).
It was that intense interest in how to make a game that led me to inspect some of the source code Microsoft
provided with QBASIC. After learning PRINT, INPUT,
IF..THEN, and GOTO (and of course SomeLabel: to go to)
I was ready to take a shot at my first text-based adventure game.
The game wasn't all that big - consisting of a few rooms, the NEWS
directions, swinging of a sword against a few monsters, and keeping track of treasure and stats for everything -
but it was a complete mess.
The experience with QBASIC taught me that, for any given program of sufficient complexity, you really only
need three to four language constructs:
Even the control structures may not be necessary there. Why? Suppose you know a set of operations will
be performed an unknown but arbitrary amount of times. Suppose also that it will
be performed less than X number of times, where X is a known quantity smaller than infinity. Then you
can simply write out X number of conditionals to cover all the cases. Not efficient, but not a requirement
Unfortunately, that experience and its lesson stuck with me for a while. (Hence, the title of this weblog.)
Side Note: The number of language constructs I mentioned that are necessary is not from a scientific
source - just from the top of my head at the time I wrote it. If I'm wrong on the amount (be it too high or too low), I always appreciate corrections in the comments.
Since all I knew about were the escape codes and the blocks (alt-177, 178, 219-223 mostly), naturally
I used the MS-DOS Editor to create my own art. The limitations of the medium were
strangling, but that was what made it fun.
And I'm sure you can imagine the pain - worse than programming in an assembly language (at least for relatively
Nevertheless, the experience taught me some valuable lessons:
Even though we value people over tools, don't underestimate
the value of a good tool. In fact, when attempting anything new to you, see if there's a tool that can
help you. Back then, I was on local BBSs, and not
the 1337 ones when I first started out. Now, the Internet is ubiquitous. We don't have an excuse anymore.
I can now navigate through really bad code (and code that is limited by the language)
a bit easier than I might otherwise have been able to do. I might have to do some experimenting to see what the symbols mean,
but I imagine everyone would.
And to be fair, I'm sure years of personally producing such crapcode also has
something to do with my navigation abilities.
Perhaps most importantly, it taught me the value of working in small chunks and
taking baby steps.
When you can't see the result of what you're doing, you've got to constantly check the results
of the latest change, and most software systems are like that. Moreover, when you encounter
something unexpected, an effective approach is to isolate the problem by isolating the
code. In doing so, you can reproduce the problem and problem area, making the fix much
The Middle Years (included for completeness' sake)
The middle years included exposure to Turbo Pascal,
MASM, C, and C++, and some small experiences in other places as well. Although I learned many lessons,
there are far too many to list here, and most are so small as to not be significant on their own.
Therefore, they are uninteresting for the purposes of this post.
However, there were two lessons I learned from this time (but not during) that are significant:
As you can tell, I was quite the cowboy coding young buck. I've tried to change that in recent years.
How ColdFusion made me a better programmer when I use Java
Although I've written a ton of bad code in ColdFusion, I've also written a couple of good lines
here and there. I came into ColdFusion with the experiences I've related above this, and my early times
with it definitely illustrate that fact. I cared nothing for small files, knew nothing of abstraction,
and horrendous god-files were created as a result.
If you're a fan of Italian food, looking through my code would make your mouth water.
Forget about it. I still thought code reuse meant copy and paste.
Still, ColdFusion taught me one important aspect that got me started on the path to
Object Oriented Enlightenment:
Database access shouldn't require several lines of boilerplate code to execute one line of SQL.
Because of my experience with ColdFusion, I wrote my first reusable class in Java that took the boilerplating away, let me instantiate a single object,
and use it for queries.
How Java taught me to write better programs in Ruby, C#, CF and others
It was around the time I started using Java quite a bit that I discovered Uncle Bob's Principles of OOD,
so much of the improvement here is only indirectly related to Java.
Sure, I had heard about object oriented programming, but either I shrugged it off ("who needs that?") or
didn't "get" it (or more likely, a combination of both).
Whatever it was, it took a couple of years of revisiting my own crapcode in ColdFusion and Java as a "professional"
to tip me over the edge. I had to find a better way: Grad school here I come!
The better way was to find a new career. I was going to enter as a Political Scientist
and drop programming altogether. I had seemingly lost all passion for the subject.
Fortunately for me now, the political science department wasn't accepting Spring entrance, so I decide to
at least get started in computer science. Even more luckily, that first semester
Venkat introduced me to the solution to many my problems,
and got me excited about programming again.
I was using Java fairly heavily during all this time, so learning the principles behind OO in depth and
in Java allowed me to extrapolate that for use in other languages.
I focused on principles, not recipes.
On top of it all, Java taught me about unit testing with
JUnit. Now, the first thing I look for when evaluating a language
is a unit testing framework.
What Ruby taught me that the others didn't
My experience with Ruby over the last year or so has been invaluable. In particular, there are four
lessons I've taken (or am in the process of taking):
The importance of code as data, or higher-order functions, or first-order functions, or blocks or
closures: After learning how to appropriately use yield, I really miss it when I'm
using a language where it's lacking.
Metaprogramming is OK. Before Ruby, I used metaprogramming very sparingly. Part of that is because
I didn't understand it, and the other part is I didn't take the time to understand it because I
had heard how slow it can make your programs.
Needless to say, after seeing it in action in Ruby, I started using those features more extensively
everywhere else. After seeing Rails, I very rarely write queries in ColdFusion - instead, I've
got a component that takes care of it for me.
Because of my interests in Java and Ruby, I've recently started browsing JRuby's source code
and issue tracker.
I'm not yet able to put into words what I'm learning, but that time will come with
some more experience. In any case, I can't imagine that I'll learn nothing from the likes of
Charlie Nutter, Ola Bini,
Thomas Enebo, and others. Can you?
Posted by Sam on Jan 04, 2008 at 07:01 AM UTC - 6 hrs
At the beginning of this week's chapter from My Job Went To India,
Chad Fowler relates a story about Rao, a "mind-reading" programmer who could pick up on the
subtleties in conversations and implement code before you realized you had asked for it.
Both when I first read this, and the second time around, alarms went off in my head: "What about
YAGNI?" Why would you implement something
that wasn't asked for? If you are wrong, you could be relieved of your position for wasting
time and money.
Thankfully, Chad addressed my concerns. It turns out,
We might be standing around waiting for a pot of coffee to brew, and I would talk about how
great it would be if we had some new flexibility in our code that didn't exist before. If I
said it often enough or with enough conviction, even though I hadn't really put it on the
team's TO-DO list, Rao might fill the gaps between "real work" looking at the feasibility of
implementing one of these things. If it was easy (and cheap) to implement, he'd whip it
out and check it in.
Chad also mentions the potential pitfalls in such an approach:
You waste time and money if the functionality was not needed
You increase complexity of the code base and make "it less resilient to change" if your
code forces "the system down a particular architectural path."
You could unintentionally make the application "less functional or desirable to the customer."
Honestly, I'd caution against using this advice unless you are in one of the following situations:
You've known the feature-requester long enough that you can pick up on things he's asking for, but hasn't
yet asked for. I think you should be really close in this situation. How can you predict otherwise?
There is obviously something missing from the spec, and you have enough experience with
similar systems to know it is missing. This might be something like "We need a login system."
You can probably safely assume they'll need a way to log out as well, and perhaps even
"I forgot my password" functionality.
The logout functionality I'd almost always toss in (unless requested otherwise). However, even
on the "forgot password" feature, I'd consider a couple of things. First, do I know the customer
well enough that we've done another application for them and they wanted it? Second, is the
budget big enough to where I know they won't be upset if I implement it?
There could be more, but that's what my brain thought of this morning. Of course, in many
cases it's just better to ask first.
Posted by Sam on Dec 21, 2007 at 12:38 PM UTC - 6 hrs
This seems to be becoming a theme here lately: DIFN.
That's the advice in MJWTI for this week, although Chad Fowler doesn't put it so bluntly.
In the chapter, Chad describes a race where the first team to complete a project over the weekend wins $100 thousand. Could you do it?
How is it that an application
of similar scope to those we spend weeks working on in the office is going to get
finished in a single weekend?
We've all seen projects take weeks when they could be measured in days. So what gives?
The answer, of course, is that we aren't accustomed to doing it right now. Stop putting off tasks. Just do them.
To help meet that goal and create race conditions, I like to timebox my daily tasks.
From 5:30 to 6:15 I read my email do my morning blog reading. Then I take 15 minutes and enjoy a cold Red Bull. After that, I might work on Project A for 3 hours, then read email for 15 minutes. I've got half a days work done before most people get to the office. After that, I might switch to Project B for three more hours, and so on.
To keep track of what I should be working on and give myself pop-up reminders that it's time to change tasks, I've been using Apple's iCal, and it works pretty well.
My only problem is that as I need to work more often in Windows, I'm not using it as much, and particularly this week my productivity has been way down. (I admit, the impending holiday may have something to do with that as well.) However, FedEx just dropped off VMWare Fusion, so hopefully I won't need to boot into Windows anymore and the problem will be solved.
My only complaint against iCal itself is that I wish I didn't have to set up an email address in the mail client for it to send me an email - that's just annoying.
If you're not on a Mac, Google Calendar would work (except you're not getting the popup reminders). Even just spending 15 minutes before you leave work to plan the next day, and writing it on the whiteboard or some sticky-notes would likely be a major improvement for your work-day, and might even be better than a technology-based solution.
How have you made it easier on yourself to do it right now?
Posted by Sam on Dec 14, 2007 at 03:33 PM UTC - 6 hrs
This week I return to following the advice in Chad's book. It's something I've been doing now for a while: automation.
I'm really big into automation - one of the things I really like to do is create developer tools, or even just small throwaway scripts that get
me through the day.
One paragraph that stuck with me was this one:
So, imagine your company is in the business of creating websites for small
businesses. You basically need to create the same site over and over again,
with contacts, surveys, shopping carts, the works. You could either hire
a small number of really fast programmers to build the sites for you, hire
an army of low-cost programmers to do the whole thing manually and
repetitively, or create a system for generating the sites.
Sound like anyoneyouknow? (Or any of the other people writing generators, automated testers, and the like?)
It was after reading that paragraph that I decided we needed to change things at work. Forget about code repetition, there was plenty of effort repetition as well. The first part of that process was getting cfrails together, the remaining part is to build a WYSIWYG editor for building sites - if I ever get around to it.
There are other things to automate besides frameworks that generate code. Neal Ford has a pair of talks (both links there are PDFs found via his past conferences page) he gives that illustrate a bunch of tips and "patterns" along these lines. I enjoyed both of them and will eventually get around to reviewing them. He also
mentioned that a book covering the topic is coming soon.
Getting back to MJWTI, Chad lists a "simple (minded) formula" to calculate productivity:
productivity = # projects or features or amount of work / (# programmers * average hourly rate)
At the end of the chapter he shows it in action: 5 units of work with 3 fast programmers at $80 per hour would be as productive as 20 programmers at $12 per hour on the same project (obviously ignoring the communication deficiencies and other pitfalls of a group that large). But if you are able to automate enough of your work, you can be the single programmer at $80 per hour on the same 5 units of work.
The exact math isn't what's important - the fact that you are more productive by automating as much as possible is.
In what ways do you automate your workday, no matter how big or small?
Posted by Sam on Dec 07, 2007 at 03:06 PM UTC - 6 hrs
When someone starts complaining about customers who are making silly requests, I normally say something like,
"I know! If it weren't for those damn customers, we'd have a perfect program!"
There'd be no one using it, but hey - the application would be sweeeeet.
This week I'm going to diverge from Chad's book on how to save your job. That's mostly
because I don't have the book with me, but this has been on my mind the last couple of days
anyway: the fear of success.
I've noticed it in myself and others from time to time - inexplicably sabotaging opportunities to succeed.
I try not to listen to that voice now if I can help it.
More recently, I've started to notice it in companies and customers as well - groups as opposed to individuals.
I've started wondering if reluctance to "go live" until the product was a symbol of perfection
fits in with this phenomenon.
What can we do to help them get over this irrational behavior? If they continuously request those trivial changes
and never go live, the project has failed. Do you think they will blame themselves, their ideas, and their actions?
No, they will blame you, and find someone else to work with next time.
So you may have been paid for your time, but it still impacts you negatively.
Don't get me wrong - sometimes there are good reasons to wait to release a product or service. Sometimes,
you don't need to DIFN.
However, the fear
that your customers won't know to look under "output devices" to find a subcategory of "printers" is
probably not on that list of reasons. Someone has been using a product to great advantage
for many years
and you want to "wait until you finish the last bit" to sell it as a whole to others - also probably not
on that list. You want the login on the left hand side instead of the right?
After a week of such changes, it's one thing. Six months? GMAFB.
Perhaps you'd have been better off letting your customer's use it to see if they got confused, preferred
blue links to red ones, or even happened upon an idea to make the application flow better.
So what does make the "OK to wait"-list? The fear
of underwhelming an audience with your unfinished product would, especially if you're
get to show them exactly one time. I can't think of much else that does. Can you?
So the point is that you need to get over the fear of success. Stop snatching defeat from the jaws of
victory. Let a good thing or two happen. Help your customer's get past their fears.
to recognize that fear and ignore it is something we can all do. Looking at our customer's excuses to
keep the product in the warehouse from a fear-of-success angle might provide a way to relate to them
instead of scoffing at their incessant requests for frivolity.
Success is staring you in the face. All you have to do is stick your hand out and embrace hers. Why do
you turn and run away?
I'm exploring this space for the first time.
Obviously, I have a lot of questions and very few answers. If you've got either of them, let me know
in the comments - it's always appreciated.
Posted by Sam on Nov 30, 2007 at 06:46 AM UTC - 6 hrs
Although computer science is a young field of study, it is rife with examples of good and bad
ways to do things. This week's advice from MJWTI
instructs us to focus on the past - learn from the successes and failures of those who came before
Chad includes a quote from a Jazz musician that illustrates the concept of how we
learn to become masters quite well:
My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?
Similarly, part of code practice
involves studying other people's code.
Doing so is good to teach you new tricks and things to avoid. But as
Chad also mentions, it also exposes you to projects you might not have otherwise known about -
giving you the option in the future to reuse it instead of writing your own version if your
application requires it.
But not having those books won't stop me from reading source code - I plan to start that as
part of my weekly practice sessions. It fits so well with one of the things I'm most
interested in - improving the design of my own applications.
You can say you don't run into trouble and therefore, your design is good, but how would you know until
you've gone back to it after not looking at it for a year? You need something to compare it
to, and I'm not convinced a UML diagram will suffice.
In the end, Chad gives two action items to follow up on:
Pick a project to read, make notes, and "outline the good and the bad." Use that
experience to publish a critique of
the project and it's code.
Start a study group to dissect and learn from code.
I'd like to start reading other source code, but I'm not sure when I'll publish a critique of
it. On top of that, one of the things I'd like to do in the code dojo is dissect other people's code, even
if I already find it helpful to analyze our own.
When you look at code, do you do it with a critical eye?
Posted by Sam on Nov 26, 2007 at 06:08 AM UTC - 6 hrs
Last week I posted about why software developers should care about process, and
how they can improve themselves by doing so. In the comments, I promised to give a review of
what I'm doing that seems to be working for me. So here they are - the bits and pieces that work for me.
Also included are new things we've decided to try, along with some notes about what I'd like to
attempt in the future.
Most of our business comes through referrals or new projects from existing customers.
Out of those, we try only to accept referrals or repeat business from
the "good clients," believing
their friends will be similarly low maintenance, high value, and most importantly, great to work with.
We have tried the RFP circuit in the past, and recently considered
going at it again. However, after a review of our experiences with it, we felt that unless you are the cause of the RFP
being initiated, you have a subatomically small chance of being selected for the project (we've been on both
ends of that one).
Since it typically takes incredible effort to craft a response, it just seems like a waste of hours
On the other hand, we are considering creating a default template and using minimal
customization to put out for future RFPs, and even then, only considering ones that have a very
detailed scope, to minimize our effort on the proposal even further.
We're also trying to move ourselves into the repeatable solutions space - something that really takes the
cheap manufacturing ability we have in software - copying bits from one piece of hardware storage to another -
and puts it to good use.
Finally, I'm very interested to hear how some of you in the small software business world bring in business.
I know we're technically competitors and all, but really, how can you compete with
The Software Development Life Cycle
I won't bother you by giving a "phase" by phase analysis here. Part of that is because I'm not sure
if we do all the phases, or if we're just so flexible and have such short iterations the phases seem to bleed
together. (Nor do I want to spend the time to figure out which category what each thing belongs in.)
Depending on the project, it could be either. Instead, I'll bore you with what we do pretty
much every time:
At the start of a project, we sit down with client and take requirements. There's nothing fancy here.
I'm the coder and I get involved - we've found that it's a ridiculous waste of time to pass
my questions through a mediator and wait two weeks to get an answer. Instead, we take some paper or
cards and pen, and dry erase markers for the whiteboard. We talk through of what the system should do at a high level,
and make notes of it.
We try to list every feature in terms of the users who will perform it and it's reason for existence.
If that's unknown, at least we know the feature, even if we don't know who will get to use it or why
it's needed. All of this basically gives us our "use cases,"
without a lot of the formality.
I should also note that, we also do the formal bit if the need is there, or if the client wants to
work that way. But those meetings can easily get boring, and when no one wants to be there, it's not
an incredibly productive environment. If we're talking about doing the project in Rails or ColdFusion,
it often takes me longer to write a use case than it would to implement
the feature and show it to the client for feedback, so you can see why it might be
more productive to skip the formality in cases that don't require it.
After we get a list of all the features we can think of, I'll get some rough estimates of points
(not hours) of each feature to the client, to give them an idea of the relative costs for each feature.
If there is a feature which is something fairly unrelated to anything we've had experience with, we give
it the maximum score, or change it to an "investigate point cost," which would be the points we'd need
to expend to do some research to get a better estimate of relative effort.
Armed with that knowledge, they can then give me a prioritized list of the features they'd like to see
by next Friday when I ask them to pick X number of points for us to work on in the next week. Then
we'll discuss in more detail those features they've chosen, to get a better idea of exactly what it is
they're asking for.
We repeat that each iteration, adjusting the X number of points the client
gets to choose based on what was actually accomplished the previous iteration - if there was spare time,
they get a few more points. If we didn't finish, those go on the backlog and the client has fewer points
to spend. Normally, we don't have the need for face to face meetings after the initial one, but I prefer
to have them if we can. We're just not religious about it.
Whiteboards at this meeting are particularly useful, as most ideas can be illustrated quite quickly, have
their picture taken, and be erased when no longer needed. Plus, it lets everyone get involved when we start
prioritizing. Notecards are also nice as they swap places with each other with incredible ease.
Within each iteration,
we start working immediately. Most of the time, we have one week iterations, unless there are a couple of projects going on -
then we'll go on two week iterations, alternating between clients. If the project is relatively stable,
we might even do daily releases. On top of that,
we'll interface with client daily if they are available that frequently, and if there is something to show.
If the project size warrants it, we (or I) track our progress in consuming points on a burndown chart.
This would typically be for anything a month or longer. If you'll be mostly done with a project in a week,
I don't see the point in coming up with one of these. You can set up a spreadsheet to do all the calculations
and graphing for you, and in doing so you can get a good idea of when the project will actually
be finished, not just some random date you pull out of the air.
Another thing I try to be adamant about is insisting the client start using the product as soon as it
provides some value. This is better for everyone involved. The client can realize ROI
sooner and feedback is richer. Without it, the code is not flexed as much. Nor do you get to see what
parts work to ease the workload and which go against it as early in the product's life, and that makes changes more difficult.
For us, the typical client has been willing
to do this, and projects seem to devolve into disaster more readily when they don't.
Finally, every morning we have our daily stand-up meeting. Our company is small enough so that we can
talk about company-wide stuff, not just individual projects. Each attendee answers three questions:
What did you do yesterday?
What are you going to do today?
What is holding you back
The meeting is a time-conscious way (15 minutes - you stand so you don't get comfortable) to keep
us communicating. Just as importantly, it keeps us accountable to each other, focused on setting
goals and getting things
done, and removing obstacles that get in our way.
On the code side of things, I try to have unit tests and integration tests for mostly everything.
I don't have automated tests for things like games and user interfaces. I haven't seen much detriment
from doing it this way, and the tradeoff for learning how to do it doesn't seem worth it at the moment.
I would like to learn how to do it properly and make a more informed decision though. That
will likely come when time is not so rare for me. Perhaps when I'm finished with school
I'll spend that free time learning the strategies for testing such elements.
Luckily, when I'm working on a ColdFusion project, cfrails is pretty well tested so I get to skip a lot
of tests I might otherwise need to write.
By the same token, I don't normally unit test one-off scripts, unless there are obvious test cases I can
meet or before doing a final version that would actually change something.
I don't know how to do it in CF, but when I've use continuous integration tools for Java projects it has been
helpful. If you have good tests, the CI server will
report when someone checks in code that breaks the tests. This means bad code gets checked in less often.
If you don't have the tests to back it up, at least you'll feel comfortable knowing the project builds
For maintenance, we normally don't worry about using a project management tool to track issue.
Bugs are fixed as they are reported - show stoppers immediately, less important within the day, and things deemed
slight annoyances might take a couple of days. I'd like to formalize our response into an actual policy, though.
Similarly, new requests are typically handled within a couple of days if they are small and I'm not
too busy - otherwise I'll give
an estimate as to when I can have it done.
With bugs in particular, they are so rare and few in number
that I could probably track them in my head. Nevertheless, I mark an email with my "Action Required" tag,
and try my best to keep that folder very small. Right now I've overcommitted myself and the folder isn't
empty, but there was a time recently that it remained empty on most nights.
In any event, I normally only use project management tools for very large projects or those I inherited
for some reason or another.
If you're a practitioner, you can tell the ideas above are heavily influenced by (when not directly part of)
Scrum and Extreme Programming. I wouldn't call what we're doing by either of their names. If you're not familiar
with the ideas and they interest you, now you know where to look.
Where would we like to go from here?
One thing that sticks out immediately is client-driven automated testing with Selenium or FIT.
I'd also like to work for several months on a team that does it all and does it right,
mostly to learn how I might better apply things I've learned, heard of, or yet to be exposed to.
What else? That will have to be the subject of another post, as this one's turned into a book.
Thoughts, questions, comments, and criticisms are always welcome below.
Posted by Sam on Nov 22, 2007 at 12:04 PM UTC - 6 hrs
Since the gift buying season is officially upon us, I thought I'd pitch in to the rampant consumerism and list some of the toys I've had a chance to play with this year that would mean fun and learning for the programmer in your life. Plus, the thought of it sounded fun.
Here they are, in no particular order other than the one in which I thought of them this morning:
JetBrains' IntelliJ IDEA: An awesome IDE for Java. So great, I don't mind spending the $249 (US) and using it over the free Eclipse. The Ruby plugin is not too shabby either, the license for your copy is good for your OSX and Windows installations, and you can try it free for 30 days. Martin Fowler thinks IntelliJ changed the IDE landscape. If you work in .NET, they also have ReSharper, which I plan to purchase very soon. Now if only we could get a ColdFusion plugin for IntelliJ, I'd love it even more.
Programming Ruby, Second Edition: What many in the Ruby community consider to be Ruby's Bible. You can lower the barrier of entry for your favorite programmer to using Ruby, certainly one of the funner languages a lot of people are loving to program in lately. Sometimes, I sit and think about things to program just so I can do it in Ruby.
Xbox 360 and a subscription to
XNA Creator's Club (through Xbox Live Marketplace - $99 anually) so they can deploy their games to their new Xbox. This is without a
doubt the thing I'd want most, since I got into this whole programming thing because I was interested
in making games. You can point them to the
getting started page, and they could
make games for the PC for free, using XNA (they'll need that page to get started anyway, even if you
get them the 360 and Creator's Club membership to deploy to the Xbox).
MacBook Pro and pay for the extra pixels. I love mine - so much so,
that I intend to marry it. (Ok, not that much, but I have
been enjoying it.)
The extra pixels make the screen almost as wide as two, and if you can get them an extra monitor I'd do
that too. I've moved over to using this as my sole computer for development, and don't bother with
the desktops at work or home anymore, except on rare occasions. You can run Windows on it, and the
virtual machines are getting really good so that you ought not have to even reboot to use either
Even if you don't want to get them the MacBook, a second or third monitor should be met with enthusiasm.
A Vacation: Programmers are notoriously working long hours
and suffering burnout, so we often need to take a little break from the computer screen. I like
SkyAuction because all the vacations are package deals, there's often a good variety to choose from (many
different countries), most of the time you can find a very good price, and usually the dates are flexible
within a certain time frame, so you don't have to commit right away to a certain date.
Happy Thanksgiving to those celebrating it, and thanks to all you who read and comment and set me straight when I'm wrong - not just here but in the community at large. I do appreciate it.
Do you have any ideas you'd like to share (or ones you'd like to strike from this list)?
Posted by Sam on Nov 16, 2007 at 01:15 PM UTC - 6 hrs
The chapter this week from My Job Went to India
tells us to "Practice, Practice, Practice." It's pretty obvious advice - if you practice something,
you will get better at it. Assuming that skill has value, you'll be able to market yourself easier.
What's not so obvious is that we are "paid to perform in public - not to practice."
Unfortunately, most of us practice at our jobs (which is another reason we started the Code Dojo).
Perhaps because the advice seems so obvious is why when I reread this chapter, I realized I hadn't
done much about it. Sure, I do a lot of learning and coding on any given day, but it's been
rare where I've truly stretched the bounds of my knowledge and skill. And as Chad notes in the
chapter, that is precisely the point of practice.
Specifically, we might focus on three areas when practicing, which parallel Chad's experience
as a musician:
Physical/coordination: Visiting "the dusty corners of your primary programming
language," such as deep exploration of regular expressions, tools, and APIs you
rarely (or never) get a chance to use at your day job. I'd put learning other
languages here, and experimenting with new constructs and paradigms, like you can
win an iPod Nano for doing.
You may not use it often, but when you need to, you'll be prepared. On the other hand,
you may find something that used to take you hours can be done in one line of code - it's
built right into the language.
Sight reading: If you can sight-read code, how much faster would you be at finding and
diagnosing problems, or adding new features, just by having the ability to understand
the structure of an application instantly? Chad recommends going to the to-do list
of an open source application, deciding on a feature to implement or bug to fix, and
then going through the source to find out where it needs to go. Impose time constraints on
yourself, and rotate through many different projects (and languages), and you'll get
faster at "sight reading" code. You don't even need to implement it - just finding the
place to put it would be enough (but it would be even better if you did!).
Improvisation: Chad defines improvisation as "taking some structure or constraint and
creating something new, on the fly, on top of that structure." One such example he
recovering lost data by manually replaying packets over a wireless
network from a binary log file. No body meant for you to do these things, especially
not in the heat of the moment. [But] that kind of sharp and quick programming ability
can be like a magical power when wielded at the right time.
Of the three, I really like his ideas on practicing improvisation: "Pick a simple program, and
try to write it with [self-imposed] constraints." One example is printing the lyrics to
99 Bottles of Beer on the Wall "without doing any variable assignments." Or golfing.
I'm sure you can think of others (and I plan to).
I haven't done as good a job at practicing as I'd like to, so I'm going to resolve to sit down
weekly and just have some practice time, stressing the points above. I won't be too ambitious
though - I've already over-committed myself for the rest of this year. But as my early
New Year's Resolution, I'll plan on blogging my weekly experience in regularly scheduled practice,
like Scott Hanselman does in his series, The Weekly Source Code.
Anyone want to lend some moral support and start practicing too? We could be like virtual
workout partners, flexing our coding muscles.
Note: I didn't do a good job of showing it in the article itself, but all the quotes there
are from Chad Fowler.
Posted by Sam on Nov 12, 2007 at 10:36 AM UTC - 6 hrs
I was in a conversation recently about our mission and vision statements, and how it is important to have them as a model of what your company is trying to do, and what it would like to be doing in the future.
Posted by Sam on Nov 09, 2007 at 06:03 AM UTC - 6 hrs
This week I've decided to cover my progress in two chapters of Chad Fowler's book,
My Job Went to India,
because they go hand in hand with the motivation behind much of my career management in the time since
I've read the book.
I already had one semester of graduate school under my belt by the time I read the book, so
when I got to these two chapters - Find a Mentor and Be a Mentor - I realized I was in a great
position, especially for finding a mentor. I hadn't decided whether or not to graduate under the
thesis option, or just take extra classes and do the non-thesis option. Choosing the thesis option
would be a great way to get into a relationship with a mentor, so I decided to go that route
after reading the book.
Unfortunately, I quickly found out that the one professor I wanted as an advisor would be
leaving soon and was not taking any new students. But I didn't let that stop me. Sure,
a formal relationship with a mentor is nice, but as Chad mentions in the book, you can have
mentors who don't even know they are filling that role for you.
So I started becoming involved online - asking and answering questions in topics of interest to me. Answering questions is
particularly beneficial, because you get to throw ideas into the arena and see if your expert
"mentors" will disagree with you and correct you when you are wrong. In fact, there's nothing
on this blog I enjoy more than when someone disagrees with me in a comment* (with substance, anyway).
On the other hand, when you are right
you learn that you are right and you reinforce that knowledge.
I also made it a point to sit in the front row (or close to it) of every class and ask questions to aid
in my understanding of the subject matter. I started visiting conferences and talks and user group
meetings to learn from other developers when time permits. Some friends and I organized the
UH Code Dojo in an effort to have mentors and be mentors.
Another friend or two are helping me progress in .NET faster than I would alone and we're throwing
around the idea of forming a game development meet-up group.
I started reading blogs and participating in comments on various topics on a regular basis,
rather than just when I needed to find information on a particular problem. Several blogs cover
languages or topics I rarely use. Some cover things I've yet to use at all.
Finally, I'm planning on going deeper into bioinformatics and game development with the advanced
courses next semester, where the one-on-one time with the professor is much more like a mentoring
Notice that, excepting the Code Dojo, where our aims to be a mentor and be mentored are explicit, nothing
in the previous paragraph requires those people to know they are filling that role for me
(until they read this, I suppose).
If anyone wants to be my mentor, I can pay you with a heartfelt "Thanks!" And if you need a
mentor, don't hesitate to contact me.
I'm always glad to help when that precious combination of time and knowledge allows for it.
Do you have mentoring relationships with anyone, or any group? How does it work for you?
*: I'm starting to think everything I say is correct because I haven't had many
disagreements lately. Perhaps I need to start saying stupid things I know are wrong just
to see if you all are paying attention. I'll be a troll on my own blog.
Posted by Sam on Nov 05, 2007 at 09:16 AM UTC - 6 hrs
For the next month, I'll be running a contest here for programmers to promote learning something new.
I've had this spare iPod Nano that I've yet to use (and likely never will), I've been
covering how to save your
job with Chad Fowler's My Job Went To India, and I'm passionate about learning new things. It
seems the best way to combine all three is a contest to help me spread that passion.
Write a program in any language you are unfamiliar with.
Choose a language or a program that is in a different paradigm
than languages (or programs) you already know (how to write).
Use at least one idea from that language that you've never (or rarely) used in another language.
Make it a useful program, though it needn't be big.
Follow good programming practices appropriate to the paradigm you're programming in (as well as universal ones).
If you have a blog and want to participate, post the solution there to be scrutinized in comments.
If you don't have a blog and want to participate, email the solution to me via my
contact page or my email address if you already know it, and let others scrutinize the solution
here in the comments.
I'll get the prize out the door in time for you to receive it by Christmas, in case you want to give it away
as a gift.
When you submit your program, be sure to point out all the ways you've done the above items.
But I need your help
If you have any ideas for possible programs, list them below. This would give people something to choose from, and make for more participation.
If you have an idea that you want to do, but aren't sure if it would work, it probably will. Feel free to ask if it makes you more comfortable though.
If you think this is as important as I do, spread the word - even if you don't want to participate.
The winner will likely be chosen in a random drawing, but I need people proficient in different paradigms to help me judge what qualifies. I'm not an expert in everything.
Overall, the point is to learn something new, to have fun doing it, and to get people involved in learning new concepts.
If you accomplish any two out of those three goals within the next month, let me know
about it and we'll enter you in the contest.
Posted by Sam on Nov 02, 2007 at 06:15 AM UTC - 6 hrs
Chad summed this up for me so well in one paragraph of My Job Went To India
that I'm just going to let him say it:
Looking back on it, I realize how foolish we were. We worked for a business and our job was to contribute to either making or saving
money for that business. Yet we didn't understand the basics of how the business came to profitability.
Worse, we didn't think it was our job to know. We were programmers and system administrators. We thought
our jobs were strictly about those topics that we had devoted ourselves to. However, how were we supposed to
creatively help the business be profitable if we didn't even understand how the business worked?
As Chad notes however, "education requires both a teacher and a student. Many of us are too often reluctant to be a student." He likens fish to the "process of using a tool, or some facet of a technology, or a specific piece of information from a business domain you're working in." Too many of us take the fish today, and "ask ... for another fish tomorrow."
Being a good developer means not relying on your "server guy" to set everything up for you. Be a master of source control, testing, and of setting up your own development tools: the IDE, outside references or the build path, and the virtual machine (or whatever runs your code).
Learn how to make ColdFusion work with your database. Figure out how to install and run Rails - don't rely on it being preinstalled on Leopard.
For quite some time in college I was afraid of using the command line to compile my programs - I just wrote them in Windows using Dev C++ and turned them in, blindly hoping they would compile and work correctly for the person grading my program on Unix.
For God's sake, learn how to compile your own programs, even if modern IDEs do it onSave().
I hate to say it, but you're in the wrong line-of-work if you are constantly asking for fish. Technologies change too quickly to ask for help every time you run into a roadblock. The problem is magnified tenfold if you have to ask several times to accomplish the same task.
On another note, Chad mentions code-by-wizardry as being particularly painful:
A[n] ... easy way to get lazy is to use a lot of wizards that generate code for you. This is particularly prevalent in the world of Windows development where, to Microsoft's credit, the development tools make a lot of tasks really easy. The downside is that many Windows developers have no idea how their code really works. (page 50, emphasis mine)
I can attest to that. You know that main class that processes all the callbacks in a typical Windows program? I didn't either. Consequently, my first several forays into programming for Windows resulted in disaster. If I could find that code, I'd love to post it for inspection, so you could marvel at how Button1 did something for TextField2 and all of it somehow worked in one GodClass. The magnificence of the horror led to nightmares for me recently as I
discovered the XNA framework. The wizards are there to make your life easy - not to be a replacement for knowledge and thought. You still need to understand what they are doing for you.
The point is that you have to learn. Don't be afraid to ask, but when you ask, make sure there is a purpose behind it. If you teach yourself to learn, and you learn everything you need to know, you'll be in good shape. But, to end with some advice from an old professor of mine, be honest about what you know. Don't be afraid to admit your shortcomings - instead, use it as a chance to learn, not as a chance to have someone else do it for you.
Posted by Sam on Oct 19, 2007 at 08:21 AM UTC - 6 hrs
It's such a bit of obvious advice that I almost skipped over it: "love it or leave it." There's no point staying in a job or career that you don't like - your performance will suffer as you sling code listlessly on a daily basis.
The flip side of that is that you'll excel in something you're passionate about. It's not hard to "take a big step away from mediocrity" just by being passionate (quoting Chad Fowler, in MJWTI).
So, if you're not passionate about programming, should you find another career? Perhaps, but why not just become passionate? It's not exceedingly hard.
I know - I was there.
When making the decision to go to graduate school, I had originally planned to go for Political Science. I was bored with work, and I just wanted to get away from computers. A lot of that was self-inflicted with my spaghetti-coding ways, but I just didn't feel right programming any more. Someone with one of the coolest jobs in the world dreading to go to work? That was me.
Luckily for me, the Political Science department didn't accept Spring admissions for grad school, and that was when I wanted to enroll. So, I said "what the hell," and went for Computer Science instead. Of course, I have the benefit of having been passionate about this stuff at one point in my life. If you've never felt that way, what brought you here?
Whatever happened, I made the decision to become passionate about programming and computers again before that first semester - and now I'm hooked. My job is not appreciably different from what I was doing before - I've just added a lot of learning and exploration into my days, and figured out the benefits of dealing with crappy code. I think you can do the same.
Posted by Sam on Oct 05, 2007 at 08:45 AM UTC - 6 hrs
Those fluent in English know well the phrase
"don't put all your eggs in one basket"
(kindly linked for those unfamiliar with the idiom). If it is foolish enough to risk dropping the
basket and breaking all of your eggs, it is doubly so to put all your eggs in someone else's
basket. How could you control your destiny?
Don't do it that way is the advice from MJWTI
In particular, I want to share one passage that resonated with me:
Somehow, as an industry, we fool ourselves into thinking market leader is the same
thing as standard. So, to some people, it seems rational to make another company's
product a part of their identities.
Even worse, some base their entire careers around non-market-leading products -- at least until
their careers fail so miserably that they have no choice but to rethink this losing strategy.
Let me repeat that: some people base their entire careers around non-market-leading products.
That sounds just about where I was 18 months ago. Today, I cannot imagine basing my career around
a product, much less insignificant ones. I try to relate everything to myself in terms of ideas,
and I try to regularly experiment with the unfamiliar. Even if I were not able to do some of it at work,
it would be well worth the effort of spending a little time at home to do that.
Moving around at the whim of others. You assert no control over your own safety. If you were dropped,
what would you do?
The intersection point between the two seemingly disparate pieces of advice is that you shouldn't use your lack of experience in multiple technologies to call yourself a specialist in another. Just because you
develop in Java to the exclusion of .NET (or anything else) doesn't make you a Java specialist. To call yourself that,
you need to be "the authority" on all things Java.
Chad mentions a measure he used to assess a job candidate's depth of knowledge in Java: a question of how to make the JVM crash.
I'm definitely lacking in this regard. I've got a pretty good handle on Java, Ruby, and ColdFusion. I've done a small amount of work in .NET and have been adding to that recently. I can certainly write a program that will crash - but can I write one to crash the virtual
machine (or CLR)?
I can relunctantly write small programs in C/C++, but I'm unlikely to have the patience to trace through a large program for fun. I might even still be able to figure out some assembly language if you gave me enough time. Certainly in these lower level items it's not hard to find a way to crash. It's
probably harder to avoid it, in fact.
Posted by Sam on Aug 17, 2007 at 12:42 PM UTC - 6 hrs
This week's advice from Chad Fowler's gem of a book really resonated with me when I
read it, and it continues to do so. It was one of my favorite chapters in the book: Be a Generalist.
Don't be "just a coder" or "just a tester" or just anything. Doing so leaves you useful
only in certain contexts, when reality dictates that it would be better to be generally useful.
Towards the end of the chapter, Chad tells us about his early days in IT:
What first amazed me most when I entered the information technology field was that many
well-educated programmers (maybe most) didn't know the first thing about how to
set up the systems they used for development and deployment. I worked with developers who
couldn't even install an operating system on a PC if you asked them to, much less set
up and application server on which to deploy their applications.
After reading that, I thought to myself, "That's me." Rather than wallow in self-pity, I
decided to do something about it.
Where I used to ask "our server guy" (that's his official name) to do something,
I started asking him how to do it. ButI didn't immediately start there - I started trying
to figure it out on my own before going to him for help (à la Mr. Raymond's famous
guide). Now I don't need help in setting up virtual directories or web sites or my development environment (yes,
I was that bad).
The chapter ends with advice to "list the dimensions on which you may or may not be generalizing your
knowledge and abilities" and to do something about it. There are an "infinite number" of aspects for
which you could do it, but Chad limits his discussion to five: "Rung on the career ladder, Platform/OS,
Code vs. data, Systems vs. applications, [and] Business vs. IT."
I've got a long way to go, but I'm slowly getting to where I want to be. Are you doing anything?
Posted by Sam on Aug 07, 2007 at 05:53 PM UTC - 6 hrs
This week's advice from My Job Went to India is easy to follow: invest in yourself. In particular, Chad mentions some advice found in The Pragmatic Programmer. Namely, that you should learn a new language (every year). But don't just learn any language - it should be a paradigm shifting language. In other words, "don't go from Java to C#." Go from ColdFusion to Haskell or Java to Ruby or Visual Basic to Lisp.
To illustrate the point, Chad tells the story of the developer who, when asked about having used a particular technology, replied, "I haven't been given the opportunity to work on that." Unless you don't own a computer (which Chad says probably was the case for that developer), you don't need the opportunity to be given to you. You need to take some time and do it yourself.
As I said in the last post about this book, I used to be that developer. Since then, I've improved myself considerably in Java and learned a great deal about Ruby, among other things.
But asking "what's your new language this year?" misses the point. The big shift comes when you accept responsibility for your own improvement. Once you've done that, instead of feeling threatened by new (to you) technologies, you start to embrace them.
Now, instead of avoiding projects in unfamiliar territory, I'm asking for them. Instead of laying down to be steamrolled by something I've yet to try, I take at least a few minutes to familiarize myself with it, like I did recently with ANTLR. When I've got a bit of extra time on my hands, I'll go all out and even do something useful with it.
Posted by Sam on Aug 04, 2007 at 01:15 PM UTC - 6 hrs
Before reading Chad's book, I was a one-"stack" kind of programmer. I knew a bit about Java and .NET, and I was fairly competent in C and C++ (though I wouldn't say I knew much about OO). I had done a couple of things in PHP and ASP. But for the most part, I was only using ColdFusion and Microsoft SQL Server on Windows with IIS as the web server. Consequently, I knew HTML and a bit of CSS too. I largely shied away from learning anything new, and tried my hardest to only work with what I knew well.
That sounds incredibly unlike me now. Although the change was occurring before I read his book (as evidenced by the fact that I was reading it in the first place), it certainly helped accelerate things.
(Let me also say I feel weird posting a link to the book each time I write one of these, but I don't want someone new to come along and think "WTF's he on about?" So for all you regulars, please ignore what must seem like link spam for the greater good of improving oneself: I'm not a PragProg salesman or affiliated with them in any way. Though I am an affiliate with Amazon, I don't get any special consideration for promoting this book out of all the other things I could be writing about.)
Anyway, Chad suggests making "a list of early, middle, and late adoption technologies" (page 23). Then, note the one's you're strong in, ones you have some experience in, and some you have no experience in. Try to notice any pattern there. And finally, "are there any technologies around the far edges that you have some special interest in?" Those are the high risk/high reward type cases where there is more money to be made. The middle has many more jobs, but also much more competition from other programmers.
So here's a small list I made (from early adoption to late adoption). A + marks technologies I'm fairly strong in while a - is just some experience. I 'm trying to be honest with myself, so call me out if you think I've got something wrong:
Late adoption: ASP(-), JSP(+), ASM, Visual C++(-), COBOL
I'm not sure where CF belongs, honestly. Certainly not early adoption. It's in the middle somewhere, but I don't know how early in the middle or how late. I'm tending later. For Java, I put it near late adoption because I think its importance as a language is diminishing, though its importance as a platform will remain steady.
I'm not sure where to put PHP either honestly. I almost went with late adoption because I can't foresee myself ever looking for a job doing PHP. But that's just me. I certainly don't think its importance is on the rise, however. Of course, I don't think that about CF either, given prevailing attitudes.
That's just a few large things- a lot related to web development (since that's what I'm most familiar with). I'm also having trouble thinking of technologies I have no experience in whatsoever. There are tons, to be sure, I'm just not finding any when it comes to the language level of granularity. What important languages have I missed? I know I missed SmallTalk, but I don't know whether to put that in early or late adoption. At the moment it belongs in late, but will its importance rise?
Anyway, what does your list look like? What technologies are missing from mine and where would you put them on the curve?
To combat code monkey syndrome, Chad suggests we have lunch with business people and read trade magazines for our business domains as often as we can.
Working for a tiny consulting company, I get the benefit of being close to all the business decisions, but not in many specialized domains. However, since I made the decision to stop being a "code robot" (Chad's term), I've always taken the opportunity to talk with clients or meet them for lunch to discuss their domains. Even more recently, a couple of us here have taken to reading trade publications related to a product we're building.
Doing so helps you understand why some of those "crazy" requests are made, and what you can do to make them work in the system while still accomplishing the client's goals. And things just seem to work better that way. Nowadays, I'm no longer getting any "that's a nice system, but it's not what I wanted" comments due to keeping myself stuck in a walled garden. Instead, I'm building software customers want and will use. And the purely selfish benefit: I'm adding to my value as an employee or contractor in those domains.
As an aside, last week I was on vacation, so that's why you didn't see this then. I'll try to make up for it and post two this week.
So are you a code monkey? Are you trying to evolve into a code human?
Posted by Sam on Jul 14, 2007 at 03:37 PM UTC - 6 hrs
For the next 52 weeks, I'll be following (and sometimes dispensing) advice from Chad Fowler's conveniently packaged one-chapter-per-week-in-a-year book,
My Job Went to India and how to save your job without writing spaghetti code (like me) so that only you can disentangle the mess.
(It's an important book). Anyway, today marks start of the first week. (Let's do 7 plus or minus 2 days)
Anyway, back to what we can learn from Chad...
In the first nine chapters, Chad tells us how to choose the right market.
So for my first week, he addresses supply and demand: first we want to search jobs in
our home country, as well as those available offshore. Compare the results and highlight
skills in demand in your home country that nobody (or very few people) offshore is offering.
Then, you just need to become good at those technologies that are in demand but
aren't yet available offshore (or in high supply). This is simple economics.
To get a head start, you might want
to watch the
alpha geeks and see what they're doing, but you can probably afford to start a little
farther along on the curve.
Sounds easy enough. So, start googling. Better yet,
why doesn't someone create a service that performs this search and analysis for us?