My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement | getting started with cfrails
This is the "z0mg it's Christmastime and have I really left so many of my goals for the year incomplete?!" edition of Programming Quotables.

If you don't know - I don't like to have too many microposts on this blog (me on twitter for that), so save them up as I run across them, and every once in a while I'll post a few of them. The idea is to post quotes about programming that have one or more of the following attributes:
  1. I find funny
  2. I find asinine
  3. I find insightfully true
  4. And stand on their own, with little to no comment needed
It's up to you decide which category they fall in, if you care to. Anyway, here we go: More...

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!



The Pragmatic Bookshelf has recently published The Passionate Programmer: Creating a Remarkable Career in Software Development, (or you can save a few bucks at Amazon). It's the 2nd edition of My Job Went To India, a book I think is a must-read for any programmer.

It was important enough to me that I dedicated an entire category of this blog to discussion about about it, in fact.

More...


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.
Would that help? I've already resolved to do the boring work with a smile, but something like that might help the smile not feel forced.

What do you think?


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...


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...


This morning, Leila asked how I got my groove back:
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...


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...


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.

A while back, Reg Braithwaite challenged programing bloggers with three posts he'd love to read (and one that he wouldn't). I loved the idea so much that I've been thinking about all my experiences as a programmer off and on for the last several months, trying to find the links between what I learned from certain languages that made me a better programmer in others, and how they made me better overall. That's how this post came to be. More...


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...


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...


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 anyone you know? (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?


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...


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:
Imitate. Assimilate. Innovate.
We saw a longer version of that in a quote from Ron Jeffries in last week's post about getting good at the process of software development: More...


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...


Since the gift buying season is officially upon us, I thought I'd pitch in to the rampant consumerism and list some of the toys I've had a chance to play with this year that would mean fun and learning for the programmer in your life. Plus, the thought of it sounded fun. Here they are, in no particular order other than the one in which I thought of them this morning: More...


The chapter this week from My Job Went to India tells us to "Practice, Practice, Practice." It's pretty obvious advice - if you practice something, you will get better at it. Assuming that skill has value, you'll be able to market yourself easier.

What's not so obvious is that we are "paid to perform in public - not to practice." Unfortunately, most of us practice at our jobs (which is another reason we started the Code Dojo).

Perhaps because the advice seems so obvious is why when I reread this chapter, I realized I hadn't done much about it. Sure, I do a lot of learning and coding on any given day, but it's been rare where I've truly stretched the bounds of my knowledge and skill. And as Chad notes in the chapter, that is precisely the point of practice.

Specifically, we might focus on three areas when practicing, which parallel Chad's experience as a musician: More...


I was in a conversation recently about our mission and vision statements, and how it is important to have them as a model of what your company is trying to do, and what it would like to be doing in the future.

It got me to thinking about why, as a programmer, it is important to understand the basics of business.

Without understanding the company mission or vision, how can you support the business goals and aspirations? Without knowing them, how can you understand them?

We're in the process of redefining ours. What are yours? Do you have a personal mission and vision for your career? Can you boil it down into a couple of concise sentences?

That's one I'm going to have to think about. But I'd love to hear your ideas...


This week I've decided to cover my progress in two chapters of Chad Fowler's book, My Job Went to India, because they go hand in hand with the motivation behind much of my career management in the time since I've read the book.

I already had one semester of graduate school under my belt by the time I read the book, so when I got to these two chapters - Find a Mentor and Be a Mentor - I realized I was in a great position, especially for finding a mentor. I hadn't decided whether or not to graduate under the thesis option, or just take extra classes and do the non-thesis option. Choosing the thesis option would be a great way to get into a relationship with a mentor, so I decided to go that route after reading the book. More...


2nd Generation iPod Nano The Contest
For the next month, I'll be running a contest here for programmers to promote learning something new. I've had this spare iPod Nano that I've yet to use (and likely never will), I've been covering how to save your job with Chad Fowler's My Job Went To India, and I'm passionate about learning new things. It seems the best way to combine all three is a contest to help me spread that passion.

In particular, since I think it's useful to learn languages and different programming paradigms, that's what this contest will focus on.

Here are the rules:
  • Write a program in any language you are unfamiliar with.
  • Choose a language or a program that is in a different paradigm than languages (or programs) you already know (how to write).
  • Use at least one idea from that language that you've never (or rarely) used in another language.
  • Make it a useful program, though it needn't be big.
  • Follow good programming practices appropriate to the paradigm you're programming in (as well as universal ones).
  • If you have a blog and want to participate, post the solution there to be scrutinized in comments.
  • If you don't have a blog and want to participate, email the solution to me via my contact page or my email address if you already know it, and let others scrutinize the solution here in the comments.
  • I'll get the prize out the door in time for you to receive it by Christmas, in case you want to give it away as a gift.
  • When you submit your program, be sure to point out all the ways you've done the above items.
But I need your help
  • If you have any ideas for possible programs, list them below. This would give people something to choose from, and make for more participation.
  • If you have an idea that you want to do, but aren't sure if it would work, it probably will. Feel free to ask if it makes you more comfortable though.
  • If you think this is as important as I do, spread the word - even if you don't want to participate.
  • The winner will likely be chosen in a random drawing, but I need people proficient in different paradigms to help me judge what qualifies. I'm not an expert in everything.
Overall, the point is to learn something new, to have fun doing it, and to get people involved in learning new concepts. If you accomplish any two out of those three goals within the next month, let me know about it and we'll enter you in the contest.

You have until December 5. Start coding.


Chad summed this up for me so well in one paragraph of My Job Went To India that I'm just going to let him say it:
Looking back on it, I realize how foolish we were. We worked for a business and our job was to contribute to either making or saving money for that business. Yet we didn't understand the basics of how the business came to profitability. Worse, we didn't think it was our job to know. We were programmers and system administrators. We thought our jobs were strictly about those topics that we had devoted ourselves to. However, how were we supposed to creatively help the business be profitable if we didn't even understand how the business worked?
To combat this, I took a business course that helped me understand competitive advantage, among other things. Also, in the "Act on it!" section of the chapter, Chad mentions a book, The Ten-Day MBA 3rd Ed.: A Step-By-Step Guide To Mastering The Skills Taught In America's Top Business Schools. I've just gone to Amazon to buy it myself.


You need to take responsibility for your own improvement. That's a good part of what Chad Fowler's MJWTI focuses on getting you to realize. This week's advice follows along that same line: "Give a man a fish; feed him for a day. Teach a man to fish; feed him for a lifetime" (quoting Lao Tzu).

As Chad notes however, "education requires both a teacher and a student. Many of us are too often reluctant to be a student." He likens fish to the "process of using a tool, or some facet of a technology, or a specific piece of information from a business domain you're working in." Too many of us take the fish today, and "ask ... for another fish tomorrow." More...


It's such a bit of obvious advice that I almost skipped over it: "love it or leave it." There's no point staying in a job or career that you don't like - your performance will suffer as you sling code listlessly on a daily basis.

The flip side of that is that you'll excel in something you're passionate about. It's not hard to "take a big step away from mediocrity" just by being passionate (quoting Chad Fowler, in MJWTI).

So, if you're not passionate about programming, should you find another career? Perhaps, but why not just become passionate? It's not exceedingly hard. I know - I was there.

When making the decision to go to graduate school, I had originally planned to go for Political Science. I was bored with work, and I just wanted to get away from computers. A lot of that was self-inflicted with my spaghetti-coding ways, but I just didn't feel right programming any more. Someone with one of the coolest jobs in the world dreading to go to work? That was me.

Luckily for me, the Political Science department didn't accept Spring admissions for grad school, and that was when I wanted to enroll. So, I said "what the hell," and went for Computer Science instead. Of course, I have the benefit of having been passionate about this stuff at one point in my life. If you've never felt that way, what brought you here?

Whatever happened, I made the decision to become passionate about programming and computers again before that first semester - and now I'm hooked. My job is not appreciably different from what I was doing before - I've just added a lot of learning and exploration into my days, and figured out the benefits of dealing with crappy code. I think you can do the same.


Those fluent in English know well the phrase "don't put all your eggs in one basket" (kindly linked for those unfamiliar with the idiom). If it is foolish enough to risk dropping the basket and breaking all of your eggs, it is doubly so to put all your eggs in someone else's basket. How could you control your destiny? More...


The last bit of advice from Chad Fowler's 52 ways to save your job was to be a generalist, so this week's version is the obvious opposite: to be a specialist.

The intersection point between the two seemingly disparate pieces of advice is that you shouldn't use your lack of experience in multiple technologies to call yourself a specialist in another. Just because you develop in Java to the exclusion of .NET (or anything else) doesn't make you a Java specialist. To call yourself that, you need to be "the authority" on all things Java. More...


This week's advice from Chad Fowler's gem of a book really resonated with me when I read it, and it continues to do so. It was one of my favorite chapters in the book: Be a Generalist.

Don't be "just a coder" or "just a tester" or just anything. Doing so leaves you useful only in certain contexts, when reality dictates that it would be better to be generally useful. More...


This week's advice from My Job Went to India is easy to follow: invest in yourself. In particular, Chad mentions some advice found in The Pragmatic Programmer. Namely, that you should learn a new language (every year). But don't just learn any language - it should be a paradigm shifting language. In other words, "don't go from Java to C#." Go from ColdFusion to Haskell or Java to Ruby or Visual Basic to Lisp.

To illustrate the point, Chad tells the story of the developer who, when asked about having used a particular technology, replied, "I haven't been given the opportunity to work on that." Unless you don't own a computer (which Chad says probably was the case for that developer), you don't need the opportunity to be given to you. You need to take some time and do it yourself. More...


Before reading Chad's book, I was a one-"stack" kind of programmer. I knew a bit about Java and .NET, and I was fairly competent in C and C++ (though I wouldn't say I knew much about OO). I had done a couple of things in PHP and ASP. But for the most part, I was only using ColdFusion and Microsoft SQL Server on Windows with IIS as the web server. Consequently, I knew HTML and a bit of CSS too. I largely shied away from learning anything new, and tried my hardest to only work with what I knew well. More...


As I've mentioned before, I used to try my hardest to avoid contact with the customer, and as software developers, I think we don't spend enough time concerned about the business aspects of what we do.

In My Job Went to India, Chad Fowler says he thinks so too.

To combat code monkey syndrome, Chad suggests we have lunch with business people and read trade magazines for our business domains as often as we can. More...


For the next 52 weeks, I'll be following (and sometimes dispensing) advice from Chad Fowler's conveniently packaged one-chapter-per-week-in-a-year book, My Job Went to India and how to save your job without writing spaghetti code (like me) so that only you can disentangle the mess. (It's an important book). Anyway, today marks start of the first week. (Let's do 7 plus or minus 2 days)

By coincidence, this goes along well with the "what are you doing to become a better developer in the next six months" meme. So what are you doing?

Anyway, back to what we can learn from Chad... More...



Google
Web CodeOdor.com

Me
Picture of me