13 May 2009
I’m not kidding, you have one ugly baby.
Its not your fault…well probably not your fault.
Did you drop him a lot in the first few weeks you brought him home?
No?
Hmm….
I’ve never personally had this conversation with anyone,
::Two points
- Yes, I’ve seen this done on Seinfeld...if you haven’t watched Seinfeld go grab a copy of the complete series. It still holds up.
- I actually did see someone tell somebody their puppy wasn’t cute...so sort of in the same vein as telling someone their child is ugly. Needless to say, “awkward” doesn’t being to describe the mood the conversation took on.
I digress…::
I’ve never seen anyone tell a parent their child is ugly, however, when it comes to creating software, I advocate telling people who write ugly code that yes, indeed, your code child is ugly.
First, for those of you who don’t design software and write code for a living a little background on the parent/child relationship people have with their software.
Software, like children, requires massive amounts of time and energy. You, as a designer/architect/coder, conceive the code, often times starting with little more than a blank page. From there, you outline the basic functions of your code, you test your code to make sure it meets specifications, and you clean up your code to ensure it follows all of the best practices dictated by your company. Hopefully, in time, when your code is completed you can send it off to play with all of the other code in the system. With any luck, you’ve written a good piece of software that is well behaved, has good manners, and is robust enough to function for many years to come with very little maintenance.
However, with all of the work that goes into the code sometimes it just turns out ugly.
What is ugly code? Ugly can be described in so many ways…it could be:
- Inefficient, taking way too long to perform simple tasks
- Overly complex, possibly a piece of code performs a task in 50 lines where if someone took some time with the code and refactored it the same task could be performed in 10.
- Incorrect, not producing the correct results.
This is by no means a complete list, but a small sample of items I have run into in my career.
Like anything anyone spends any amount of time with people often grow attached to their output. With such an attachment people do not take kindly to having that output being called ugly, be it real life children or code ‘children’.
However, as I have said, it must be done…
To their code children, not their real life children…. geez you are a monster. I’m not sure you should continue reading this blog…
If you can control yourself and your urges for calling kids ugly please continue, we have much to discuss. Otherwise, I bid you good day.
How you tell someone they write ugly code is up to you. I don’t advocate sending a company wide email letting everyone know that Johnson can’t write a for loop to save his life, and he would serve the betterment of mankind if he never touched another keyboard. No, that’s just mean.
Nor would I post their code on the refrigerator and write a large ‘F’ on top of it with a red sharpie…although humorous, after sending that first company wide email Johnson may get the impression of not only do you think he is a horrible coder, but you might not like him either.
No, I’ll leave the delivery of the bad news to the parent of the ugly code up to your discretion, but something must be said, because lets face it, that ugly code child is going to grow up and become your whole team’s responsibility.
Failing to correct ugly code when it is first generated leads to all sorts of problems and heartache. Firstly, for you, you will likely be the one on call when the code begins to fail in your company’s application, and it will be up to you to fix it at 3am on Christmas Eve. You will be up all night attempting to track down the module that is failing, and once you find it you will attempt to get something working as quickly as possible, because every second the system is failing your company is losing money.
This is no way to conduct a career…working under the gun to fix a problem, hopefully you didn’t cause. Especially if it could be avoided by telling the original designer they created one ugly child, and you, for one, do not want to support it when it starts misbehaving and throwing a temper-tantrum.
I recommend several steps in approaching and telling someone they have just written some ugly code:
- Come out and say, ‘I’m not calling your code ugly, but we need to talk about how you implemented requirements x, y, and z.‘
- Lay it on the table that there are concerns about the code, not the person who wrote the code. Attempt to separate the parent from the child.
- I suggest approaching this situation as a learning exercise. Point out why you believe the code, although possibly technically correct, has room for improvement.
- Make sure people know during this exercise this isn’t an indictment on their ability to program or create working algorithms, it just so happens this one isn’t up to snuff and needs some work. The important point is to stress this isn’t personal and you hope to fix the code to avoid problems in the future.
- Be able to back up your suggestions on how to fix the code with industry standards. Share with the individual why you believe their approach isn’t quite correct and show how it is done everywhere else in the industry. Even if you don’t have Johnson’s full respect it is very difficult to argue with how the rest of the world performs a task.
Lastly, put others at ease around you by inviting them to call your code ugly. Separate yourself from what you have created and attempt to learn from their years of experience. It’s the ability to take criticism and to learn from it that will help you grow in your career.
09 May 2009
This article was kicked up last week on Hacker News, http://news.ycombinator.com, and I thought I would share it here with the group.
The Management Myth by Matthew Stewart:
http://www.theatlantic.com/doc/print/200606/stewart-business
This is a long article…long even by my standards. Set aside some time and curl up with your laptop and a frosty mug of your favorite beverage.
For those of you who find you can’t spare half a day’s time reading about management theory, and who can blame you, allow me to sum up a few of Stewart’s key points regarding modern business management:
- Management books are bunk, don’t waste your time
- Frederick Winslow Taylor, author of the Principles of Scientific Management, is regarded as the father of scientific management. Steward describes how Taylor formed his management theories with a short story about a bunch of workers moving pig iron.
- The story goes...ask a bunch of workers to perform a task as quickly as they can for a short period of time. Take that data and extrapolate out what a worker could do in an entire day. Lastly account for lunch, breaks, and rest periods
- In this instance Taylor took precise measurements of how much work was being done over a short period of time, but when he accounted for breaks Taylor just picked a number out of thin air.
- The question arises, why perform such detailed analysis of the work and then just throw a giant fudge factor into the equations when accounting for everything else?
- Although most modern management books treat Taylor as a footnote in the history of management, at the core of all of these books are the same principals...appear to have a scientific measurement of how to manage people and then throw in a giant fudge factor to account for the ‘human’ aspect of management.
- The article goes on to describe the work of Professor Elton Mayo in the 1920s, describing that if people care about what they do they will work harder for the greater good of the company. This is the ‘humanist’ theory of management.
Stewart sums up these two viewpoints:
Between them, Taylor and Mayo carved up the world of management theory. According to my scientific sampling, you can save yourself from reading about 99 percent of all the management literature once you master this dialectic between rationalists and humanists. The Taylorite rationalist says: Be efficient! The Mayo-ist humanist replies: Hey, these are people we’re talking about! And the debate goes on. Ultimately, it’s just another installment in the ongoing saga of reason and passion, of the individual and the group.
I’ve read this article a couple of times now, and have spent a considerable amount of time reflecting back on how I manage the people under me. As I look back on my career I can recall instances where I have managed using both methodologies, I’ve been Tayloritte and a Mayo-ist, and I don’t believe I’ve settled on either side…I’m not sure I am supposed to pick a side.
I have to ask myself, what is the point of all of these management theories? What are we actually trying to accomplish when it is all said and done?
From my vantage point it appears as if we are attempting to predict the future. We are hopeful that if a person is given a task to perform, moving pig iron or writing code, that person can perform that task in a certain period of time. Based on those estimates we can hopefully derive when the assigned task will be completed and when we can ship product.
I believe I’ve been reading the wrong books in a vain hope to predict the future…Stewart goes on to conclude:
The tragedy, for those who value their reading time, is that Rousseau and Shakespeare said it all much, much better. In the 5,200 years since the Sumerians first etched their pictograms on clay tablets, come to think of it, human beings have produced an astonishing wealth of creative expression on the topics of reason, passion, and living with other people. In books, poems, plays, music, works of art, and plain old graffiti, they have explored what it means to struggle against adversity, to apply their extraordinary faculty of reason to the world, and to confront the naked truth about what motivates their fellow human animals. These works are every bit as relevant to the dilemmas faced by managers in their quest to make the world a more productive place as any of the management literature.
I think I’m going to take Stewart’s advice, I’m dumping my management books and I’m cleaning out my Amazon wish list this afternoon. I am going to replace those books with books written by the greats.
Define greats however you like, and yes, Douglas Adams does count.
06 May 2009
This summer I will be starting my seventh year at Viewpoint Systems…wow, seven years…that’s an eternity in the software world. Anyone remember the Pentium 2 and how they were packaged in those large black cassettes? Is anyone still using AIM, or are you one of the cool kids who is ‘facebooking’ and ‘twittering’? The list of technologies that have risen and fallen in the past seven years is overwhelming.
I probably landed at my current job much like many of you have found yours, through an interview. I just happened to have my first interview on campus, and my future CEO was causally swearing five minutes into our first meeting.
What? You haven’t had an interview where there was some causal swearing involved? You obviously haven’t lived.
It was the fall of my senior year at Cornell and interviews were in full swing. The weather in Ithaca was finally turning from gray and windy to cold, gray, and windy. Legend had it if one were to glance into the sky one might catch a glimpse of a rather large fireball, that when stared at for too long would cause a man to go blind. Some would call this fireball the sun; while others would call those same people liars…no one has ever seen the sun in Ithaca.
Needless to say the weather was changing, and interview season was upon us. My resume was newly minted, my clothes were cleaned, my ties were pre-tied…I was ready to interview for my future full time position.
What I wasn’t ready for was an interviewer who looked over my resume to exclaim, “You worked for company xyz? Those guys are a bunch of assholes!”
This really threw me off my game.
Up to this point I had been through my fair share of interviews, two different co-ops, an on campus technical position, and in high school I worked after school for the computer services department. Each interview had their own quirks…
::For my high school position I interviewed in front of no less than seven people in a big auditorium. Question: how do you strike the fear of God into a high school student? Line that student up in front of a group of supervisors, upperclassmen, his CS teacher, and ask him technical questions::
I have, however, up to this point, never actually had anyone swear during the interviews…I quickly decided this wasn’t going to be your typical interview, or typical company.
The incident stuck with me for the next several days, and through to my other interviews. It made a lasting impression, and dare I say may have been the deciding factor for the reason I took the job I now hold?
No.
It would be a very silly thing to take a job based on casual swearing, but it did make a hell of an impression on me.
Did I find the use of the swear profane or offensive? No…it was just the right use of swearing in the right situation that made all of the difference. In this case it formed an impression on me about how a small company in Rochester, NY might be a little different than say a cooperate behemoth in Seattle, WA.
To this day, that still holds true…so as I am about to start my seventh year with Viewpoint I’ll take a moment to look back and take stock on how I arrived here. I’ll reminisce about the good times, the bad times, the hard times, and the plain old fun I’ve had over the past seven years. Lastly, I ponder how large a part the word ‘assholes’ has had in me arriving to where I am today.
01 May 2009
It is that time of the year again, where managers and employees alike sit down and attempt to sum up an entire year in a few short pages or less, in a little process I like to call “Writing the Yearly Review”.
I hate this time of year.
::change my voice to that of a child about to throw a tantrum::
Writing yearly reviews is all hard and stuff, they require a lot of thinking and work, and they take me away from architecting, writing code, and playing with cool toys.
::I suggest turning the child voice off for the remainder of the post, however go sick and leave it on…I leave it to the reader’s discretion::
Review preparation and writing is a difficult, tedious process that seemingly must be performed year after year.
::Or if you are a real glutton for punishment prepared every six months.::
Needless to say while I was toiling away on this years batch I started to wonder if what I was doing was providing real value to management or to the employees? Do all of the man hours spent building the yearly review provide anything worthwhile?
Basically, why the hell are we doing these things, and are they needed in this day and age?
::Before I get too far let me go on record saying I have no idea what HR policies are in place nor do I know if there are any state employment laws that require some form of a yearly review. Let’s assume no such laws/rules exist…:
First, some sympathy to those who write the reviews…have you ever tried to write one?
Try writing your own review for your last year at work.
Go on, give it a shot. Here, I’ll provide the format:
- Start with your goals from your last review.
- Write down each goal and talk a little bit about how you went about achieving those goals
- Write down some new goals for next year
Sounds simple enough…well except for that part about the goals. Do you have clearly defined goals for your current job? Do you know them by heart? Can you rattle them off like the names of the people that make up your extended family?
Goal setting is a tricky business. How can one sum up an entire year’s worth of guidance in a few short sentences that are not only memorable but actionable?
Say for the sake of argument, you do have clear and actionable goals. Do you remember what you did during the last 12 months that moved you towards those goals? What were you doing last January that helped you realize your goals? How about last June? What about last week? What were you doing yesterday that moved you closer to your year-end goals?
Do you keep a detailed journal of your actions month-by-month, week-by-week, and day-by-day? If not, what reference material can you pull from to show you were working towards your goals?
Anyone can write in generalities, “I worked with Johnson on the Widget Tester Project, we both used our communication skills to fully execute the project last March,” but statements like these hardly contain enough detail as to what skills you actually used and how they made the project better.
::Pssst…keep a journal, summarize on a daily, weekly, and monthly basis. Not only does this CYA in the event something goes wrong, you can always look back fondly on all of your accomplishments at the end of the year and put them in your scrap book. You do scrap book don’t you? Doesn’t everybody?::
Ok, let’s further pretend you had goals and you had material to show progress on your goals. What are your goals going to be for next year? What should you be doing for the next 365 days to better yourself and “move up the corporate ladder”?
Does your company have a ridged corporate structure? Is there a clearly defined path to move up to the next rung in the ladder? Can you simply do X, then Y, and finally Z? What if projects fail to materialize where you could have done X, Y, and Z and you end up doing A, B, C, and D? Will you be an automatic failure at your next review because no opportunity existed for you to attempt to reach your goals?
We could set out some general goals…“work on public speaking skills,” “become an expert database modeler,” and “become a highly skilled assassin.”
You can set out some general goals, but why bother? General goals are rarely actionable nor memorable, and the opportunity to work towards those goals may never materialize in the coming year.
To recap:
- You likely don’t have very good goals from the year before.
- You likely don’t have the material to backup your poorly written goals.
- You can’t predict what your future goals should be nor can you write them to be actionable or memorable.
Based on this likely reality you are living in why write a yearly review?
“But Benjamin,”
::I hear you yelling at your monitor…didn’t know I could hear you did you? You don’t think Apple puts all those mics on all of those computers and leaves them turned off do you?::
“…I actually have great goals that I have worked towards, I have lots of material to back them up, and we have done a great job creating goals in the past, we should be able to create some new goals this year. Why not write that yearly review?”
Yes, why not indeed?
See, here’s the rub…this yearly review I’m about to write for you, the one you are begging for me to produce, is going to take quite a few man hours to generate and is late by about 364 days. The review will contain no surprises to either one of us, and frankly if there are a bunch of surprises in the review neither one of us is doing our job very well.
If your car was making a horrible metallic clicking sound every time you drove to work would you wait for your annual inspection to have someone look at it? If so remind me not to buy your car second hand even though you say it is in great shape, and you are letting it go for thousands below the blue book value.
Real problems are tackled on the day the occur, or hopefully soon after. Even minor problems with automobiles don’t fester for long before, hopefully, they are attended to. If your car’s windshield wipers were about to go, how long do you wait to replace them? It may not get done the next day, but it also doesn’t take a year to go get the item fixed.
If someone is kicking ass for me on a project or job I let them know then and there. I want to reinforce all good behaviors, skills, and/or commitment while it is happening. I don’t want to capture it in a note and bring it up a year later…by that time all of the luster of the good “event” has worn off, and recognizing it a year later may actually be insulting.
I say the hell with the yearly review, if you manage people let them know on a regular basis how they are doing, good and bad. Don’t wait for some arbitrary date a year in the future and attempt to create a document that takes lots of man hours to produce to deliver news hopefully you and your employee already know.
Plus, with this new system in place I won’t have to write your review anymore, I don’t have to use my child tantrum voice, and I can go back to architecting, coding, and playing with cool toys.
30 Mar 2009
Shortly after I wrote about my lack of a rubber ducky something strange happened…three rubber duckies showed up on my desk. Naturally I gave them all good homes.
The first stayed on my desk at home…
The second is living on my desk at work in a makeshift pond:
The last is living in my car:
Now no matter where I am I have a rubber ducky to talk things over with.
I want to thank my wife Vanessa for the rubber duckies, her continual support, and for taking the time to read my blog.
