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?
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 May 02, 2008 at 08:02 AM UTC - 5 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?
Posted by Sam on Apr 28, 2008 at 08:29 AM UTC - 5 hrs
When I was younger I was "an arrogant know-it-all prick" at one point in the "middle years" of my programming experience, as many of you know from the stories I often relate on this weblog.
The phrase "middle years" doesn't give us a frame of reference for my age though. For instance, if I were 50 years old right now, my "middle years" of programming may have been when I was in my thirties. That's not the case, and I want to give you that frame of reference: I'm 28 at the time of this writing. The middle years as I talked about them would have referred to my late teens to early twenties. Maybe even up to the the middle of my twenties.
More...
By most standards, that's young.
And I know a thing or two about being set in your ways. We can all see the laugh I have at myself with the title here being "My Secret Life as a Spaghetti Coder" and some of the stories I've told as well.
In fact, let me add to the wealth of stodginess, idiocy, and all around opposite-of-good-developerness here:
I once said I preferred Windows to Linux. While that's not a completely shocking statement, the reason behind it was: I said I preferred Windows because 14 year olds work on Linux. Not because of any experience I'd had with it, but because of my fear of learning it.
Because of my prior experience being unwilling to learn, I was quite interested when I read this:
When you are young, you don't have that sense of self to protect. You're driven by a need to find out who you are, to turn the pages of your biography and see how the story turns out. If people around you are doing something you don't understand, you assume the problem is your inexperience and you go to work trying to understand it.
But when you are old, when you know who you are, everything is different. When people around you are doing something you don't understand, you have no trouble at all explaining why they are assholes mistaken.
. . .
If you want a new idea, you have to silence your inner critic. Your sense of right and wrong, of smart and stupid works by comparing new ideas to what you already know. Your sense of what would be a good fit for you works by comparing new things to who you already are. To learn and grow, you must let go of you, you must be young again, you must accept that you don't understand and seek to understand rather than explaining why it doesn't make any sense.
In a couple of paragraphs, Reg sums up almost precisely some of what I've been thinking and writing about for the last several months. He's so close, but misses a fundamental point: the old and young parts are incidental.
My hypothesis is that the level of learning and idea absorption you can attain has little to do with age. Instead, it is influenced more by your perceived level of experience. Normally, age is highly correlated to experience - but it doesn't have to be. In my case, when I was younger I thought I knew everything. Now that I've aged, I came to the realization I know very little.
My conclusion is not that different from Reg's, and this is not some scientific experimental contest, so let me explain why I feel the difference is worth noting: If we blame our reluctance to try new things on age, we are dooming ourselves to think of it as some unchangeable, deterministic process. By thinking of it in terms of perception of experience, we admit to being able to control it with more ease. (My belief is that we have control over what and how we perceive things.)
In other words, we lose our ability to blame anyone but ourselves. That's a powerful motivator sometimes.
Thoughts? Disagreements? Please be kind enough to let me know.
Posted by Sam on Apr 25, 2008 at 07:10 AM UTC - 5 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.
Let me put that another way: Perception is reality. Get over it.More...
Last week, we finished the section of MJWTI that dealt with executing when we discussed the importance of commitment, and executing on that commitment. This week, we begin adventuring into the world many of us have absolutely no clue about: marketing.
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:
Group
Perception Drivers
Teammates:
Technical skills, social skills, teamwork
Manager:
Leadership ability, customer focus, communication skills, follow through, teamwork
Customers:
Customer focus, communication skills, follow through
Project Manager:
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.
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.
More...
"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 16, 2008 at 07:22 AM UTC - 5 hrs
I don't like to have too many microposts on this blog, so I've decided to save them up and start
a Programming Quotables series. The idea is that I'll post quotes about programming that have one or more of the
following attributes:
I find funny
I find asinine
I find insightfully true
And stand on their own, with little to no comment needed
Here's the fifth in that series. I hope you enjoy them as much as I did:
More...
At this stage, if you've heard of Rails and you haven't converted, it's entirely possible that you never will. It's also entirely possible that anybody who still isn't even taking Rails seriously by this point might just be some kind of idiot.
...
Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down.
Instead, I want to talk about my first attempt at solving the puzzle, which was an utter failure. A glorious, spectacular failure. Perhaps the single most impressive failure of my career. Failures are often much more interesting than successes, but for some unfathomable reason, people are often reluctant to discuss them.
Me: read file blah.txt and display it on system output
Java: How should I name the class?
Me: Test
Java: How should I handle errors?
Me: I don't care right now, I just need to display that data to system output
Java: But I need to know this, what if something unexpected happens?!
Me: I just want to make a prototype damn it!
Java: Sorry, can't do it.
Me: Ok, do nothing on error.
Java: And which implementation of Stream class should I use for reading?
Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job.
Neal Ford and others have been talking about the distinction between dynamic and static typing as being incorrect. The real question is between essence and ceremony. Java is a ceremonious language because it needs you to do several dances to the rain gods to declare even the simplest form of method. In an essential language you will say what you need to say, but nothing else. This is one of the reasons dynamic languages and type inferenced static languages sometimes look quite alike - it's the absence of ceremony that people react to.
Posted by Sam on Apr 11, 2008 at 11:44 AM UTC - 5 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:
More...
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.
Posted by Sam on Apr 04, 2008 at 07:27 AM UTC - 5 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:
More...
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 Mar 28, 2008 at 05:46 AM UTC - 5 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.)
More...
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?
Posted by Sam on Mar 14, 2008 at 05:14 AM UTC - 5 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
say).
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 07, 2008 at 02:39 PM UTC - 5 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:
More...
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.
Deep words.
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 Feb 29, 2008 at 10:58 AM UTC - 5 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.
More...
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
significant.
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 Feb 22, 2008 at 07:26 AM UTC - 5 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?"
Posted by Sam on Feb 15, 2008 at 08:22 AM UTC - 5 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
excel."
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 - 5 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:
More...
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.
Know anyone like the horror-story? Anyone who has overcome that superiority complex?
Posted by Sam on Feb 01, 2008 at 07:59 AM UTC - 5 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.
More...
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.
More...
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 - 5 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."
More...
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 - 5 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:
Input
Output
Conditional statements
Control structures
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
either.
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.
What ANSI Art taught me about programming
When I started making ANSI art, I was unaware
of TheDraw. Instead, I opened up those .ans files I
enjoyed looking at so much in MS-DOS Editor to
see how it was done. A bunch of escape codes and blocks
came together to produce a thing of visual beauty.
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
small programs).
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
easier.
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.
DRY principle?
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?
What's next?
Missing from my experience has been a functional language. Sure, I had a tiny bit of Lisp in college, but
not enough to say I got anything out of it. So this year, I'm going to do something useful and not useful
in Erlang. Perhaps next I'll go for Lisp. We'll see where time takes me after that.
That's been my journey. What's yours been like?
Now that I've written that post, I have a request for a post I'd like to see:
What have you learned from a non-programming-related discipline that's made you a better programmer?
Posted by Sam on Jan 04, 2008 at 07:01 AM UTC - 5 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,
More...
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.
(emphasis mine)
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 - 5 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?
More...
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 - 5 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 - 5 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.
More...
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.
Changing ourselves
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 - 5 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
us.
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 - 5 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.
More...
Preproject Considerations
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
to pursue.
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
this?
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
successfully.
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.
Summary
If you're a practitioner, you can tell the ideas above