Finishing strong

Usually, if you are about to leave a job, it’s hard to stay motivated. Other than tying up any loose ends, it’s probably not a good idea to start something you can’t finish.

As my final days with kajeet approached, I seem to be more productive than I think I was in awhile. I really was in support mode so I didn’t have a large number of tasks on my plate. I used this extra time to do some engineering-inspired projects (as opposed to business initiatives). In something that reminds me of Google’s 20% time, I was able to work on projects that meant something to me personally.

I prototyped a single-sign-on application. I built an application based off an idea our engineering team had months ago but never had the time to act on. It got demoed and was received well by the company. It took less than 16 man hours to build and business saw value in it. Hopefully, it will be officially launched.

After doing this, I am a fan of the 20% time. Being able to work on things you’re passioniate about and sharing it with others is, well, the whole idea, isn’t it?

I hope to see more companies, especially startups, adopt this practice. The engineers are happy and the return on investment is tremendous. Of course, this only works if you have an awesome engineering team, people that truly love to code. That shouldn’t be a problem though, you don’t really want the other kind of engineer.

Anyways, back to the point of this post. Leaving jobs is a stressful time. You worry if you are making the right decision. You worry if the relationships you’ve developed are going to continue. You worry if you will get to play ping pong at work..oh wait, we’re talking about startups right?


Mortal Kombat - Finish Him


Regardless, I think it’s important to finish strong in everything you do. I took it as a challenge to see how much I could accomplish in my last two weeks, committing code up to the last day of employment. It’s a great feeling when you know you leave a place better than you entered.

Finishing strong

Prior work experience not needed?

Jeff Atwood just posted an article on the myth that the more years of experience a developer has, the better candidate they are for a position. In the article he references a previous post that spoke to the hypothesis that there is no correlation between skill in programming and experience. This is exactly what I was thinking when I wrote my reaction to disillusioned young IT workers.

I’m still early in my career and I’ve tried to stay on a career path that is driven by what I enjoy doing, which is hacking away at code. At the same time, I am not blind to the fact that companies do look for work experience in specific areas. This certainly helps you get your foot in the door. One thing I’ve struggled with is how do you make the transition into getting that sought-after experience?

While I have programmed in a number of different programming languages, these experiences are based on my own pet projects and curiosity of the languages. On the other hand, my professional experience can be summed up as a Java developer. I’ve been working with Java since I got out of school. While I think working with Java is great since I feel I can be productive in it and there are plenty of career opportunities, the IT industry evolves over time and we see other languages gain traction.



I don’t have any hard statistics, but I suspect the number of core programming languages an average developer extensively works with throughout their career is probably around 10-12. If you count all the supplemental languages that come with working in certain languages, like HTML, JavaScript, or SQL, this number is probably closer to 20. That sounds like a reasonable guesstimate and if true, I’ve got a long way to go.

This got me thinking about how do I continue to learn if my day-to-day is limited to one programming language. Here’s some advice I have for other Java developers.

  • Follow open source – open source projects are a great way of getting exposure to a lot of the Java/JEE platform. The Java platform is a really big environment to be playing with. Open source has provided baselines for everything from database ORM projects like Hibernate/iBatis to MVC frameworks like Spring MVC/Struts to messaging infrastructure with ActiveMQ/Mule to web services with Xfire/Axis2. There is a lot to be learned and I never see a job description for Java developers without some mention of a Java open source project.
  • Change the focus – What I mean here is change what you are doing most of your work relative to the system. At my first job, I mainly worked on the front-end so it was all HTML/CSS/JSP and Controllers. After awhile, I was interested in doing more of the back-end and building out infrastructure with DAOs and web services. At my current employer, I started off again on the front-end. Luckily, it was with a different MVC framework so there was good exposure there. More recently, I’ve had the opportunity to work on infrastructure and I’ve been exposed to about five new technologies I never worked with before.

By doing this, I’ve gained a lot of experience in a short amount of time with respect to working in Java. Basically, it allowed me to get more in-depth experience with Java by using Java in different contexts. This is a great start and if I was planning on working with Java my entire life, I could always continue down this path but that’s not reasonable.

HR departments love to see previous experience and it reminds me of the catch-22 that recent college graduates face. They want a job but the employer wants prior experience. They can’t get experience if the employer doesn’t them a job.

I would love to hear from people who have worked with multiple programming languages and made the language transition between jobs. If a company had a .NET position or a Rails position and you never had experience in the language, what made the company hire you and allowed you to beat out other candidates that probably had more language experience than you? What inspired you to make the paradigm shift? What advice do you have for others developers with language-limited experience?

Prior work experience not needed?

Top 8 Unix Commands for the Developer

As a developer, there are certain UNIX commands you find yourself typing repeatedly. Whether it’s to debug a production issue or just modifying some files, these commands have helped me do my job time and time again. Here’s my top 8:

  1. grep – Prints the lines that match the pattern provided in the files specified
    • Usage: grep <options> <pattern> <files>
    • Example: grep -n Exception production.log
      • Prints all the line (showing line numbers) in the file production.log that contain the string ‘Exception’
  2. tail – Only interested in a the last couple of lines in a file? tail allows you to quickly view the end of the file
    • Usage: tail <options> <file>
    • Example: tail -fn100 production.log
      • Shows the last 100 lines of the log and waits to display any new text appended to the file
  3. ssh – Log into remote servers
    • Usage: ssh -p<port> <username>@<hostname>
    • Example: ssh -p1234 theo@production
      • Logs into the server named production on port 1234
  4. scp – Copies files to/from remote servers
    • Usage: scp -P<port> <source> <target>
    • Example: scp -P1234 /home/theo/myfile.txt production@/home/jsmith
      • Copies myfile.txt from /home/theo to the server named production under /home/jsmith
  5. rm – Deletes stuff!
    • Usage: rm <options> <file>
    • Example: rm -rf mydir
      • Removes the entire directory and files with no prompt for confirmation (Use with caution!)
  6. ps – Shows process status
    • Usage: ps <options>
    • Example: ps aux
      • Displays the process status of processes for all users including those that are controlled by a terminal (system processes) sorted by CPU usage
  7. top – Similar to ps but it periodically updates the information such as CPU and memory usage
    • Usage: top
    • Example: top (duh!)
  8. kill – terminates a process
    • Usage: kill <option> <pid>
    • Example: kill -9 12345
      • Terminates the process with id of 12345 using a non-catchable, non-ignorable signal (that just means you REALLY mean to kill it)

I use lots of these commands in combination. For example, if tomcat seems to hang and won’t properly shut down I would do the following:

  >> ps aux | grep tomcat

I would then take the pid of tomcat and run:

  >> kill -9 <tomcat-pid>

Now you may be wondering why the “Top 8”, why not “Top 10”. Well, because 8 is the new 10 and those are all UNIX commands I know :).

What are some of the commands that you use to get through the day?

Top 8 Unix Commands for the Developer

A Case for Agile: Benefits for a Programmer’s Career

After graduating college as a computer science major and preparing to enter the work force, I found that there is a big gap between what you learn in college and the practice of being a software engineer.

In college, you learn the the basics of data structures, OOP, and algorithms. But being a software engineer is so much more than that. At my first job out of college, I was lucky enough to be a part of a great team of engineers. They understood the value of best practices, introducing me to design patterns, the power of open source, and how to approach hard problems.

However, it was very one dimensional. While I improved my technical experience, I really didn’t get a chance to be exposed to other perspectives. What I mean is it was very much like college again. My work was my own work. I studied, researched, and provided answers. I didn’t really collaborate with my coworkers. I was given an assignment and an estimated deadline and I would do it kind of like homework.

At my second and current job, I’ve been introduced to and been practicing agile software development, more specifically Scrum, on a daily basis. I’ve seen the HUGE personal benefits that a software engineer, like myself, can take away from developing software this way.

I’ll break it down through what is known as the four values of Agile Software Development.

Individuals and interactions over processes and tools
While being exposed to version control, bug tracking, and continuous integration systems is great for a resume, working with other human beings is much more rewarding and fun. You develop strong relationships and you are able to learn so much from other people’s experiences and perspectives. Pair programming has helped me develop a better understanding of what I don’t know and an even stronger understanding of what I already know. And it’s not only other developers you develop these relationships with. As requirements change, you interact with people from marketing, product, legal, qa, project managers, designers, and the list goes one. This is something you would never get as a programmer at an IT shop that practiced something like the Waterfall method for development, especially early in your career. You will be pigeon-holed into just being code monkey by the time the requirements get to you. Being able to interact with different types of people allows you to grow your network and it exposes you to different aspects of a business.

Working software over comprehensive documentation
As developers, we just like to get things done. We have a tendency to measure productivity with written code. With agile, we can embrace this 100%. I get to concentrate on writing bug fixes, add new features, refactor code, improving the build process rather than documenting some API that no one will ever need since the code is self-documenting. I take great joy in actually doing what I love doing and that’s coding. However, it is a fallacy to interpret this value to mean I don’t have to document anything. But whenever there is no documentation, don’t blame agile. Just rely on the first value and ask someone what that method does.

Customer collaboration over contract negotiation
Developers don’t usually have face to face time with actual paying customers. Usually the “customer” is some other department in the company asking for a new development feature. The main point to be made here is that you want to engage the stakeholders. Not only do you develop relationships, you gather in-depth knowledge of what problems other people are facing on a daily basis. Understanding requirements is often the most difficult part of developing software. As requirements change, with constant engagement from the customer you have a better chance at meeting those requirements. The other piece of this value has to do with deadlines. Contracts are hard deadlines. In the software development, with all its moving pieces, it’s pretty silly to commit to arbitrary dates six months from today. But if you engage stakeholders into your development process, they have clear visibility into the progress of the project. You don’t have to make excuses for why the project is late. They already know what you’re working on and where you are. How does this benefit you? Well, you get to deliver software that actually meets the customer’s needs. Who’s the rock star now?

Responding to change over following a plan
Nothing is ever set in stone. Being able to respond to the evolution of a project is critical to a project’s success. If you are able to learn to design programs that have the flexibility to adapt to your business, that is one awesome accomplishment. It’s a great feeling to be able to say to a product manager that his requested change is already supported by the system, it’s just a configuration change. The language you are using now is most likely not the one you will be using in the future, if you choose to remain a developer. Being able to respond to this change in sought after skills will benefit you well.

Through agile development, I’ve been able to deliver working software time and time again. I’ve been exposed to all different aspects of the business. I’ve learn what I like and don’t like to do. I’ve learn what pieces of business I’m interested in and the pieces I don’t care much for. I’ve developed some really good working relationships. I’ve tackled some hard problems. I’ve learned to respond and adapt to the change and turmoil of a startup.

Most importantly, I still feel I’m growing as a developer. I honestly believe the best thing a developer can do in their career is to always be learning. Everything else will follow.

A Case for Agile: Benefits for a Programmer’s Career

Re: Young IT workers disillusioned

After reading this article, I had to vent on the ridiculousness of the article.

The article is pretty much a summary of a survey done by an IT staffing firm. It states that entry-level, 20-something year old employees are the most difficult to manage because they have high expectations from their employer. High expectations like good salaries, bonuses/rewards, and an office. Some pointy-haired boss mentioned in the article said “the problem between employers and the younger generation just entering the workforce can be traced back to the employees’ upbringing or an easier way of life for children in the United States today.”

With condescending statements like that, why would I want to work for you? This sounds like a classic “When I was your age”-ism that creates a crappy work environment.

I’m in the IT industry, I’m a 20-something year old, and I guess you could still consider me “entry-level”. I’m not disillusioned about my place in the industry. I don’t expect you to give me the title of CTO of a Fortune 500 company. I don’t need a secretary and a personal assistant. I do however expect to be paid accordingly to the value I bring the company. Why wouldn’t someone want to be rewarded if they do outstanding work? Not having a reward doesn’t stop me from doing outstanding work. You need to find employees that hold themselves to a higher standard than you do. I personally don’t care for offices but it’s clear that having an door that shuts allows developers to be more production due to less distractions.

Just because I may be an entry-level employee, that doesn’t mean I bring any less value to the employer. What qualifies an employer to treat an entry-level employee as a second-class employee? In the IT industry, where experience seems to be king, I have struggled to understand why that is. Experience is fine and dandy but it only takes you only so far. Raw talent should be valued more. Between 3 rock star 20-something year olds and 3 mediocre experienced 40+ year olds, I will bet on the rock stars every single time.

It sounds to me that it’s not the young IT workers that are disillusioned but it’s the employers. They want rock stars employees without providing any incentive.

Re: Young IT workers disillusioned

Cultivating work environments

Paul Graham just wrote a very insightful piece that I hope companies take note of. The start of the essay speaks to how important it is for programmers to have the ability to store the entire context of a problem in their head so they can navigate to all the pieces they need to work on. This is key for solving big problems and facilitates effective productivity. Graham goes on to provide 8 ways to help programmers to do this.

One of the ways he suggests is to work in small groups. At my work, we do a lot of pair programming and sometimes 3-way programming. I find this to be extremely effective for the way I code. I enjoy being able to constantly ask if this is the right way to approach a problem or am I understanding the problem correctly. With pair programming, I get immediate feedback by my teammate(s) and it helps to spread knowledge of the code base without having to go through code reviews.

The second half of the essay is what really inspired me to write this post. Graham makes the claim that companies deliberately try to do things wrong when it comes to dealing with programmers.

Graham writes:

One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts.

It’s not merely true that organizations dislike the idea of depending on individual genius, it’s a tautology. It’s part of the definition of an organization not to.

The weakest point in big companies is that they don’t let individual programmers do great work.

Moral of the story: Create a work environment where developers are truly valued. They are the problem solvers. They are the closest to the product. They are the ones bubbling with ideas. Listen to them. Don’t act like a big company no matter what your size is. This is how to beat your competitors.

Cultivating work environments

Effective Meetings

After working for less than 2 years out of college, I’ve already been in more ineffective meetings than I care to count. So here’s a couple of guidelines I’ve come up with. Keep in mind, these meetings are focused around technical issues. Technical meetings are focused on coming up with a solution and are centered around the idea of Getting Things Done. I’m sure marketing meetings require a different set of guidelines since creativity requires a blank canvas.

  • Have an agenda — What is the purpose of the meeting? What does each individual want to get out of the meeting? Stick to this agenda. Don’t get side tracked. That’s what the end of meetings are for. If you didn’t walk out of a meeting with new knowledge or any actionable items, you failed.
  • Don’t go to listen — If you don’t have something to contribute, don’t waste your time going. This kills your productive for the day. You’re stuck in a meeting while you could have been building the Next Big Thing. Sure, sometimes it’s nice to stay in the loop about something but that’s what lunch, instant message, e-mail, the water cooler is for.
  • Don’t invite friends — Only the people who are critical to the meeting of being a success should attend. I used to want to be apart of every meeting everywhere and I felt left out if I wasn’t invited. But now, I feel lucky when I’ve left out.
  • Don’t have meetings to have meetings — Don’t schedule meetings just to have a meeting. There are certain things that can just be discussed by stopping by and saying “hey you got a sec?” A 20-slide PowerPoint isn’t required for everything in life, even if you were taught differently in college.
  • Have a DD – Having a designated driver is probably the most important thing. You need someone handle the check and balancing of meetings. Without a DD, there’s going to be that awkward pause some time during the meeting where no one knows what to talk about next. And then someone says “So, uhh…”

I made this list up while watching the Office so don’t listen to me. My inspiration comes from Michael Scott.

“That’s what she said.”

Effective Meetings