Tuesday, July 29, 2008

Advice for young software engineers

I LOVE working with new graduates. People fresh out of college often exhibit the natural brilliance that has not yet been diminished by years of sitting in meetings and patching old poorly written code. They are unpolluted by bad practices they have not yet learned. They are full of enthusiasm, energy, and desire to change the world.

The great new graduates are also easier to hire than the great experienced developers.

We know where both populations concentrate - great students go to top computer science schools - Harvard, Stanford, CMU, MIT, and the like. Great engineers work at the top companies - Microsoft, Google, Apple, and the like.

The key difference is that the students get kicked out of their nesting spots with an astonishing regularity. The times and places are well known - so it's easy to harvest them right at the source :-).

Consequently, I've worked with a lot of very smart young people throughout my career, as a peer, a manager, and a mentor. Invariably, they were always interested in how they could grow to be great engineers. My advice always had come down to two points:

(1) Find great people to work with. The project itself is far less important than the team that is working on it. There are no mundane projects, but there are terrible teams, and a bad team (which usually starts with the bad manager) can spoil any project, no matter how good. Consequently, look for the great manager (unless you're working at Google, then the manager does not matter) - someone who you can trust, and someone from whom you can learn a lot.

(2) Find a place where you can write a lot of low-level code. Software development is both a science and a craft. Both are equally important. Staying close to hardware (no Java! no STL! no Python or JavaScript!) will help you really "get" the computer architecture and the algorithms. That's the science part. Writing lots of code is the only way to become a master craftsman. Writing new code on your own is better than working on even the best, most complex systems that someone else had done - we learn far more by doing than by observing.

This advice probably goes against the grain. These days every one of us knows of a friend whose friend has made it doing web gigs for a startup that was acquired by another startup. The problem is that every one of us who has been in this industry for a while also personally knows 10-20 people who went from a startup to a startup, never acquired any useful skills nor made any money beyond basic subsistence level (which can be quite high in the Silicon Valley, actually).

So if you're in this industry to get rich quick by harnessing the power of web advertising, you're in a wrong industry anyway. May I suggest turning your attention to investment banking? It's more money even quicker. But if you really care about the technology - learn it in the right place, learn it by doing, and learn it deeply. I can teach C programmer Java. I don't think the reverse is true.

More here: http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html, and by the way, we're looking for people who graduated from college knowing C or C++: http://1-800-magic.blogspot.com/2008/07/looking-for-great-devs.html.

7 comments:

Anonymous said...

This is really a good post. I believe young engineers will treasure your advices.
Technolgy goes too fast, engineers are becoming farther and father from OS and low level APIs. From Pascal/C to c++, Java/C#, python/ruby; from MFC to Winform to WPF/Silverlight; We have STL, we have BCL, we have CLR/GC, we have LINQ... Seems that people are working with great productivities comparable to a programming machine, with totally forgeting of good memories and feelings they have many years ago, when they could only program C code or assembly.

-Jerry

Siam said...

Being a young engineer myself, I Just want to thank you for the great post.

Nick said...

You're so right...

Anonymous said...

I have worked in Google for 2 years. I have heard one sentence many times: "Don't re-invent wheels".

Google has its own powerful infrastructure and code framework. One could write powerful applications upon them without exactly knowing what's going on. So during work, most engineers don't have any chance to write those low level code.

For me, I was working with all kinds of scripts and java and html/js/css most of the time. And there was only one chance that I could write a simple http frontend server based on Google's C++ http server framework. I was challenged many times. "Why should you need a new frontend?" "There is a existing similar service, could you just use that one?" etc.

I understand that the "Don't re-invent wheels" philosophy is good for keeping code base tight and maintainable and thus is good for the company's growth. But that sacrifices individual engineers ability growth.

Anonymous said...

Write strcpy...

// No I don't care about the ANSI prototype or even parameter checking

void strcpy( const char* src, char* dst )
{
while (*dst++ = *src++);
}

It can be done with 1 line... yet 90% of the people I would interview that had C on their resume made no attempt to write strcpy... amazing.

I hear what's being said... but frankly I got burned out on software dev years ago... too many inflexible people, in some cases not willing to learn the very programming language they used every day. What may surprise you, it was at Microsoft... I spent 2-1/2 years at building 25. If people weren't willing to learn C++ well to design good code (remember, maintenance can and is a huge part of software development, it's the way the world works, get over it) at a place like MS, well, that didn't leave much hope for other organizations.

Even so, MS was fun and there were lots of smart people. But nowadays if you ask me to go write code, you might as well be asking me to eat sh*t.

-M

BadTux said...

I LOVE working with new graduates.

What I love about working with new graduates is that I can get them started with good habits such as, e.g., properly documenting the inputs and outputs of their object methods and subroutines. What I don't love about working with new graduates is that it takes so much freakin' *time* to get them started with good habits.

We know where both populations concentrate - great students go to top computer science schools - Harvard, Stanford, CMU, MIT, and the like. Great engineers work at the top companies - Microsoft, Google, Apple, and the like.

Wow. That is the biggest bunch of... excrement... I've ever seen. One of the best engineers I've ever worked with never went to college -- his dad worked in the industry, he spent his days reading his dad's CS books and his nights hacking on dad's source code, and while he's "self taught" he certainly is no idiot. (And of course I'll point out that I didn't go to one of the "top" schools either, but that hasn't stopped me from releasing a string of successful products over the past ten years).

As for the notion that great engineers only work at "great companies"... wow. Just wow. I'll tell you the problem with "great companies". After a while people who want to build great products don't show up at "great companies". Instead, the folks who show up are those who want to work at great companies. Call it Zawinski Syndrome, after jwz's diagnosis of why Netscape went from being a leader in browser software, to putting out a crap browser that crashed all the time. Look at SGI. One of the "great companies" of the early 90's. Quit innovating, now is gone now except for a name and a Linux cluster. Look at Sun Microsystems. Created the friggin' engineering workstation market, then created the Internet server market. Now going, fast. Look at Google. Created the world's best search engine, then... what? A bunch of crap. Nothing Google has created since that original search engine has made me want to switch to their product (e.g., I still use Microsoft Hotmail rather than gmail because, well, why would I want to switch from something that already works?). And they haven't done diddly at fixing the many, many flaws in their current search engine that make some searches pretty much impossible. They innovated, and then... well. There's blogger, but they bought that.

The fact of the matter is that the innovative stuff, the cool stuff, is not getting done at Google or Microsoft nowdays. Some of it *is* getting done at Apple, but that's because Apple has rather deliberately taken a downsized approach to the question of how to build great product, with a few people at the very top who not only come up with great ideas but have the power to force the rest of the company to implement those great ideas. I think what these "leading companies" prove is that innovation is possible in a large company only if you do like Apple and deliberately down-scale how things get done. Scale matters, and once you scale beyond a certain point, inertia takes over and it becomes damnably hard to move beyond it in a revolutionary as vs. evolutionary way. Do you really believe that the next OS innovation is going to come out of Microsoft? It is to laugh. Microsoft has too much invested in their current OS to go in and type "format C:" on the volume containing its source code and starting over from scratch with new and fresh and innovative ideas. If there are going to be any new and innovative things in operating systems, they will happen outside of Microsoft. If there are going to be any new and innovative things in search, they will happen outside of Google. And so forth.

What I'm working on right now could not be done at any of the industry leaders in that field. They simply have too much invested in current approaches to the particular problem set. So much for "great engineers work at top companies"...

Sergey Solyanik said...

Badtux,

I never said that great engineers only work at good companies, and great students only go to elite universities.

Only that it's easier to find them there, because that's where they concentrate. The probability is higher, that's all.