A Noted Path by Theodore Nguyen-Cao

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?

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.

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?

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?

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.

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.