The Knewton Blog

Our monthly newsletter features edtech and product updates, with a healthy dose of fun Knerd news.

On Becoming a Practicing Software Engineer

Posted in Knerds on March 4, 2010 by

Pete is the CTO at Knewton, where he and his team are working hard to get ready for the launch of our new SAT prep course.


If you’re a recent or soon-to-be college grad (or maybe you realized your undergrad degree in Art History ain’t gonna pay the bills) and you are passionate about computers and computer programming, here are my tips for becoming a successful practicing software engineer. Many of these things probably aren’t the things they taught you in your college programming classes, but all of these are important.

Read more after the jump.

1. Practice! Practice! Practice!

You learn to code by, um, reading and writing code! If you don’t have much experience and want to get started, find an open source project you care about and contribute a patch or two.  The “View Source” feature of Web Browsers and the open source movement are 2 of your greatest assets when learning to code.  Use them! As someone who started his career copying BASIC programs from Compute! and Byte magazines, I can’t tell you how great it was to discover the magical “View Source” menu item in Netscape.  Open Source projects will teach you about packaging, style guidelines, automated testing, bug tracking, and version control — while also giving you much needed practice. Don’t forget, your code doesn’t *work* until someone else uses it.  If you can’t work at a startup and need to get code into the hands of users quickly, open source projects are a great way to go.  I still recommend going with the startup, though.  At Knewton, everyone from summer interns to new full-time engineers ship code (that customers actually use) in their first couple weeks of starting.  I’d like to get this down to the first day.In your early practicing, make sure to develop really strong habits.  I learned the most of my habits from Steve McConnell’s Code Complete and Kent Beck’s eXtreme programming.  Write code others can support if they need to, but try to make it so they don’t need to support it :)I’d also recommend checking out PragDave’s Code Kata site to work on solving problem:

http://www.codekata.com

2. Work at a startup!

You will learn more in your first month at a startup than you will in your first year in any other company.  The first company I worked for was a 3-person shop in Syracuse, NY.  I learned everything from how to become a practicing software engineer, to how to be a customer support person, estimate and bid consulting jobs, write requirements, QA, write user manuals, configure SQL Servers, configure IIS Servers, configure linux firewalls … If your first job entails you being handed requirements that you then write code for and hand “over the wall” to QA – run!Don’t just take my word for it.  Here’s what one of our former interns who recently graduated and landed a sweet job in CO had to say:

“I had NO experience as a coder.  You guys gave me a LOT.  In fact, more skillz than you can really understand. Things that transferred over beyond Ruby, RUnit, Rails, MySQL unix commands (I’m loving that I actually understand how to use the CLI in my Ubuntu set up btw…), etc – more the ability to take a bunch of instructions I barely understood and google my way/solve my way to a solution.”

Chris Dixon also has a couple nice posts on this topic:

Joining a startup is less risky than you think.

3. More specifically, work for my startup

4. Don’t be afraid to make mistakes! or Perfection is for popes and Chinese emperors.

In 1999, I got my first big job at an online brokerage (Datek) in NYC.  This was back when everyone, probably including you, traded online and doubled their money daily – basic fundamental laws of economics changed… until they didn’t.  The day of my first big release, I took down the ability to login to the production site at market open.  This was, as my CTO at the time reminded me, “reeeeaaaaaaalllllly baaaaaddddd.”  However, we talked through the problems and took the appropriate steps to ensure I couldn’t make the same mistake again (it involved improper DB connection handling, lack of performance testing, deployment timing and rollback procedures).  If he fired me, maybe I’d feel differently about making mistakes.  Fortunately, for me, he understood these types of mistakes will happen — as long as you’re willing to grow from the mistakes and not repeat the same mistake twice.Don’t forget that coding is a creative endeavor; typically, there is no one correct solution.  Be prepared to try several.

5. Reality… zen and the art of “boring” tasks.

You studied sexy problems in school, you know how to solve nine-queens efficiently, find shortest path in a graph, compute Chebyshev distance in a metric space…the large part of your day as a software developer will not be spent working on such problems. More than likely you will spend a day on a far wider range of tasks that are comparatively less interesting in an engineering/problem-solving sense. These lower-level tasks are generally more simple and yet each decision that is made in their execution can be evaluated and perhaps improved upon. Design details as small as method signatures, naming conventions, loop constructs or recursion, tail-recursion or not (maybe even that’s too sexy!), are both extremely important and regularly overlooked. A large program is built on many lines of code. Each line contains required prior decisions to produce. An appreciation for these small details will contribute a lot not only to the quality of the program as a whole, but to the education of the coder.If you’re not already in a coding-related field, look for ways to make your current job more efficient through automation.  This can be as simple as creating access databases, word mail merges and batch files to automate tasks that used to take you hours or days to complete.  This is actually how I got my start coding professionally, by building MS Access database apps that made week-long tasks takes hours (mass mailings to customers at an HVAC rep and students at the SU Masters of Public Administration program).

6. Finish!

You don’t get any points for effort.  You need to finish what you start.  Half-written, incomplete code atrophies very, very quickly.  If you find yourself starting more than you finish, you need to revisit the scope of your problems.  Code against smaller problems, but finish the code!

While not everyone is destined to be a great coder, if you’re interested in learning how, I strongly recommend the list above.  I’m not certain this is an exhaustive list; I’d love to hear any other suggestions.  Good luck, and have fun!