I'm working at my first programming job. My boss is a very smart software engineer, and I feel
like I have very little to offer compared to him. Problem is, he is always busy, and needs someone to help him out. I feel like I'm not good enough, but I still want to succeed. I want to be a great programmer.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

4

@Pablo: Like you mentioned, just be a great programmer :)
–
Fanatic23Dec 11 '10 at 5:47

Be passionate, smart, self learner, fast learner and all in all a real problem solver :-)
–
JaniDec 11 '10 at 19:56

7

For future readers, the TL;DR answer is this: Impress your boss by leaving a thankless job to fly from Michigan to San Francisco, because the only place you can do something impressive is in a city full of fixed wheel bikes.
–
IncognitoDec 12 '10 at 3:57

21 Answers
21

Ashton was your classic corn-fed farm boy. His parents had been hippies who never really managed to get their acts together until his mother inherited 15 acres in a rural part of Michigan. The family moved out there, bought a couple of dairy goats, and struggled to make a living selling organic goat cheese to the yuppies at the Ann Arbor Farmer’s Market.

From the time he was ten years old, Ashton had to wake up every morning at 4:00 a.m. and milk those damn goats, and it was exhausting. Ashton loved going to school because it meant he wasn’t working knee-deep in goat poop. Throughout high school, he studied his ass off, hoping that a scholarship to a good university would be his ticket out of the farm. He found college to be so much easier than farm life that he didn’t understand why everyone else didn’t get straight A’s like him. He majored in Software Engineering because he couldn’t imagine engineers ever being required to wake up at 4:00 a.m.

Ashton graduated from school without knowing much about the software industry, really, so he went to the career fair, applied for three jobs, got accepted by all three, and picked the one that paid the most: something insane like $32,000 a year, working at a big furniture company in the southwestern part of the state that manufactured cubicle farms for corporations all over the world. He never wanted to see a farm again, so he was determined to make a good impression on his boss, Charlie Sherman.

“That’s not going to be easy,” his cubicle-mate, Jeff, said. “She’s something of a legend here.”

“What do you mean?” he asked.

“Well, you remember a few years ago, when there was all that uproar about Y2K?”

Ashton was probably too young. “Y2K?”

“You know, nobody expected that all the old computer programs written in the 1960s would still be running in 2000, so they only had room for two digits for the year. Instead of storing 1999, they would store 99. And then when the year flipped over on January 1st, 2000, the computer systems crashed, because they tried to fit “100” in two digits.

“Really? I thought that was a myth,” Ashton said.

“At every other company in the world, nothing happened,” Jeff said. “They spent billions of dollars checking every line of code. But here, of course, they’re cheap bastards, so they didn’t bother doing any testing.”

“Not at all?”

“Zilch. Zero testing. Nada. And lo and behold, when people staggered back into work on January 2nd, not a single thing worked. They couldn’t print production schedules. They couldn’t get half of the assembly lines to even turn on. And nobody knew what shifts they were supposed to be working. The factory literally came to a standstill.”

“You’re kidding,” Ashton said.

“I shit you not. The factory was totally silent. Now, Charlie, she was new then. She had been working at Microsoft, or NASA, or something... nobody could figure out why someone like her would be working in our little armpit of a company. But she sat down, and she started coding. And coding. And coding.

“Charlie coded for nine days straight. Nine days without sleeping, without eating, some people even claimed she never went to the bathroom. She went from system to system and literally fixed all of them. It was something to behold. My God, there were COBOL systems in there that needed to be fixed. The whole factory at a standstill, and Charlie is sending people to the university library in Ann Arbor to find old COBOL manuals. Assembly-line workers are standing around shivering, because even the thermostats had a Y2K bug. And Charlie is drinking cup after cup of coffee and typing like a madwoman.”

“Wow. And she never went to the bathroom?”

“Well, that part might be a little bit of an exaggeration. But she really did work 24 hours for nine days straight. Anyway, on January 11th, about five minutes before the day shift is supposed to start, she comes out of her cubicle, goes to the line printer, hits a button, and boom! out comes the production schedules, and the team schedules, and everything is perfect, perfectly formatted, using a slightly smaller font so that the “2000” fits where it used to say “99,” and she’s even written a new priority optimizing system that helps them catch up with 9 days of missed production without pissing off too many customers, and all the assembly lines start running like nothing was ever wrong, and the heat comes on, and the invoices come out printed with ‘2000’ as the year instead of ‘19100,’ and after that day, nobody found a single bug.”

“Oh come on!” Ashton says. “Nobody writes code without bugs.”

“She did. I saw it with my own eyes. The first day back they ran two days worth of cubicles without a hiccup.”

Ashton was dumbstruck. “That’s epic. How can I live up to that?”

“You can’t, buddy, nobody can,” Jeff said, turning back to his computer terminal, where he resumed an online flame war over who would win in a fight, Spock or Batman, which had been raging for over four months.

Not one to give up, Ashton swore he would, one day, do something legendary. But the truth is, there never was another Y2K. And nobody, in that part of Michigan, gave a rat’s ass about good programming. There was almost nothing for the programmers to do, in fact. Ashton got dumb little projects assigned to him... at one point he spent three weeks working on handling a case where the sales tax in one particular county was wrong because some zip code spanned two different sales tax zones. The funny thing was, it was in some unpopulated part of New York State where nobody ever bought office cubicles, and they had never had a customer there, so his code would never run.

Ever.

For two years Ashton came into work enthusiastic and excited, and dying to make a difference and do something terrific and awesome, while his coworkers surfed the Internet, sent instant messages to their friends, and played computer solitaire for hours.

Jeff, his cubicle-mate, only had one responsibility: updating the weekly Excel spreadsheet indicating how many people were hurt on the job that week. Nobody ever was. Once a week, Jeff opened the spreadsheet, went to the bottom of the page, entered the date and a zero, hit save, and that was that.

Ashton even wrote a macro for Jeff that automated that one task. Jeff didn’t want to get caught, so he refused to install it. They weren’t on speaking terms after that. It was awkward.

On the morning of his two year anniversary at the cubicle company, Ashton was driving to work when he realized something.

Not one line of code that he had written had ever run.

Not one thing he had done in two years of work made any impact on the world.

And it was fucking 24 degrees in that part of Michigan, and it was gray, and smelly, and his Honda was a piece of crap, and he didn’t have any friends in town, and nothing he did mattered.

As he drove down Lincoln Avenue, he saw the furniture company ahead on the left. Three flags fluttered in front of the corporate campus: an American flag, a flag of the great state of Michigan, and a white and red flag with the company logo. He got in the turning lane behind a long line of cars waiting to turn left. It always took four or five traffic light cycles, at rush hour, to make the turn, so Ashton had plenty of time to try to remember if any code he had ever written was ever used by anyone.

And it hadn’t. And he fought back a tear.

And instead of turning left, he went straight, almost causing an accident because he forgot that the left turn light didn’t mean you could go straight.

And he drove right down Lincoln Avenue, and got onto the Gerald Ford freeway, and he just kept driving until he got to the airport over in Grand Rapids, and he left his crappy old Honda out right in front of the terminal, knowing perfectly well it would be towed, and didn’t even close the car door, and he walked right up to the Frontier Airlines counter and he bought himself a ticket on the very next flight to San Francisco, which was leaving in 20 minutes, and he got on the plane, and he left Michigan forever.

you can't leave me hangin like this. where is Chapter 2 of this story :)
–
mikealDec 11 '10 at 6:53

50

Am I stupid for not understanding the moral of the story? :(
–
Terence PonceDec 11 '10 at 7:15

39

Then Ashton said "looked at my kingdom I was finally there, to sit on my throne as the prince of Bel-Air." Sorry couldn't resist.
–
JinDec 11 '10 at 10:06

37

The moral is if you aren't making a difference in your job or have any opportunities to advance, get a job where you will. I've been in a situation where I knew I was good at my job, but my boss was old fashioned and inflexible and I knew I wouldn't get anywhere, so I left. Best career decision I ever made.
–
Simon HibbsDec 11 '10 at 11:07

149

The story continues: He went to work for Google, where he worked on Wave. And again, noone was using his code.
–
Ivo van der WijkDec 11 '10 at 13:55

Remember the scene in Aladdin where Aladdin wants to impress Jasmine, and the genie tells him he'd do better to just focus on being himself? Same principle here.

If the boss is that much better than you and you know it, he probably knows it too. He isn't expecting any great feats of programming rock-stardom out of you. Since this is your first job, he most likely hired you because he saw the potential to become a good coder in you. So if you really want to impress him, learn. Learn the language, learn the system you're working on, learn the ins and outs and dark corners. Focus on learning correct principles, learning them well and learning them quickly, in that order.

And remember that part of learning is copying knowledge that other people already have. Don't be afraid to ask questions, either of your coworkers or on StackOverflow, or research things on Google. Whatever you do, don't pretend you know something when you really don't, in an effort to avoid seeming dumb. Any good developer will notice quickly, and that will make you look even stupider in their eyes. Humility tends to still be considered a virtue among engineers.

+1 for the things to focus on and the mentioned order.
–
basaratDec 12 '10 at 3:58

3

Exactly. Even in game programming school I'm one (or the one) who ask questions all the time. But you also have to understand that people don't have always the answer, even a teacher. Several times a teacher answered "i don't know" to me, and I didn't feel proud, but more like "I would better have searched this before wasting this guy's time". Curiosity, just like in sciences, is the BEST VIRTUE you can think to have. Seriously, google any words about some subject you are wondering about. Curiosity is the best learning engine I have, that is the difference between people you call smart and oth
–
jokoonDec 12 '10 at 13:20

3

you know you're in a bad place in life when you're taking cues from a Disney movie.
–
EpagaDec 17 '10 at 12:48

In your position, you weren't hired to be the smartest person on the team. You were hired for the potential you showed and because there are tasks suited for your skill level that need getting done.

Show that you can live up to that trust first, and as you get a feel for the code and the company, find ways to exceed their first impression of you. The latter may take a while, but don't mistake being junior for being inferior.

What seems like forever ago I took an amazing job working with room full of amazing and accomplished programmers. Everyone was a rockstar, a few people from the original Macintosh team, almost half the people there had published books, it was a great place to be.

So I spent my first year there trying to impress everyone. I felt like I had to do somethign amazing and it drove me to learn more than I ever thought possible in a very short amount of time. In my second year I calmed down, I was a lot more confident in what I was doing, a little more vocal about my opinions, and as I looked around I grew more and more pessimistic about the actual product we were building.

That was the last year that project was fully funded. Those amazing engineers, who I still look up to today, spent 5 years and millions of dollars building framework after framework, an application platform for building on top of an application that hadn't really shipped and finally, a UI and workflow that nobody could understand, even the people that built it.

Smart is overrated. Being a "rockstar" is overrated. It's a really easy excuse to increase your threshold for complexity. It makes you think that it's more important to re-write a working system to be "cleaner" instead of implementing the next thing a customer asked for.

Jacob Kaplan Moss once said something to me about a programmer I won't name, he said "He's too smart. He writes these really smart complicated libraries that I can't use because I'm not smart enough. Stupid people should write libraries so that stupid people can use them".

The programmers that "accomplished" engineers tend to snub their nose at, people that write Ruby and JavaScript and other "toy" languages, those people make PRODUCTS and they SHIP THEM. The code might be ugly, the architecture might not be as pure and clean as you would like, but they ship god dammit and in this industry that's what really matters.

If I were you I'd give up on trying to be this rockstar and focus on shipping and building product. You shouldn't judge your contribution by how clever your code is, you should judge it by how many people run it everyday and are happy.

Truth. Write code that is easy to fix when the customers complain, or when something breaks, and you'll look like you have your shit together.
–
TehShrikeDec 11 '10 at 9:57

14

Smart is not overrated. If they built an over-complicated and out-of-touch-with-reality system then they weren't smart after all. Smart people should write libraries so that stupid people can use them.
–
EMPDec 11 '10 at 13:11

1

I had a similar conversation recently and one of my co-workers described the person code / coding style as 'pretentious'... and I think that really is an apt description... The fellow writing the code is/was brilliant... no one who knew him would disagree... but his code was horribly pretentious... which had the side effect of it being hard to follow for people that weren't similarly brilliant... I like writing code for stupid people (Makes it easier for my dumb *** to understand).
–
ThomasDec 11 '10 at 13:26

2

Teams need to be made up of different kinds of people in order to be successful. You need designers, architects, coders, managers, grunts, smart people, detail oriented people, people who care about process, etc. If you only have one type of person your team will probably not work well together and it's more likely to fail than not. Groups that try to hire only rock stars often miss that fact.
–
onedozenbagelsDec 11 '10 at 13:49

All the really good programmers I've worked with have some traits in common:

(1) Even though you don't have to be good at maths to do programming, they were anyway (and they liked it)

(2) They appreciate a quality I will call 'elegance' - not to be confused with brevity (!!!)

(3) They are good at designing software (even if none of us can explain what good design actually is)

In addition, I personally find the following traits handy:

(a) enjoying solving puzzles

(b) writing readable code

(c) a good memory

(d) can superficially adapt to other programming languages easily (breadth)

(e) learn your main language in depth (e.g. do the Java certification if Java is your environment (for clueless detractors that never did this but slag off certification since Microsoft's certification is (was?) really bad ... the benefit is not in having the piece of paper, the benefit is in the study))

(f) given the choice of doing something simple and easy and then moving on, or something super complicated that will take weeks/months, I do the simple thing. I like simple, since it tends towards robustness, also it is more flexible when requirements change in mid stride, and is a lot easier to communicate to other team members

(g) if you do something you consider especially cunning, document the smeg out of it

Someone (Djikstra?) said that debugging is twice as hard as coding, therefore if you write code that is at the limits of your ability, you are by definition not smart enough to debug it.

========

Having said that, becoming a smart/better coder is not the same as advancing your career.

There is really only one 'secret ingredient' required for advancing your career, and it is people skills.

If you really want to progress your career, the best thing to do is to quit, and go sell cars for 6-12 months.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” - Brian Kernighan
–
Ape-inagoDec 12 '10 at 7:38

4

On good memory: I knew a very good programmer with extremely good memory. He could look at the code he wrote 2 years ago and remember what he was thinking at the time. Hence, he never put much effort into writing good comments - just enough keywords to create a hash code. My memory sucks. I HAVE to comment things well because I know that 1-2 months after I filed a bug, I would have to do the same as someone completely new - e.g. read every freaking step of it. Of course, some things are more vivid that others ... I am not saying that I am a great, but maintainers and testers tend to like me.;)
–
JobDec 12 '10 at 15:33

1

Elegance and brevity have a lot in common, nonetheless.
–
Petr GladkikhDec 28 '10 at 7:34

I hv been coding for over 20 years, and currently have 10 programmers working with me. I have to say that those impresses me are those that did their job well, deliver on time and with quality (less bug). communicate frequently, showing passion are all important factors.

That is from Luke 16:10 : "He who is faithful in the least is also faithful in much; and he who is unrighteous in the least is unrighteous also in much." Also: "Well done, good and faithful slave. You were faithful over a few things; I will set you over many things. Enter into the joy of your master." (Matthew 25:21)
–
Mark CJan 26 '11 at 5:05

As Steven says, Mason is right -- focus on your own game. The thing to bear in mind is that your boss just wants you to do your own job well. He probably actually likes the fact that he's better than you -- if he wasn't, he might well end up feeling insecure (bosses are human!). Right now, you're in an ideal position to learn from his experience -- don't waste time competing with him, ask his advice on things instead. If you've ever read the 48 Laws of Power, the key one is "Never outshine the master".

If you want to make an impression on your boss, be honest. At your weekly 1-1, ask him what is most important for you to focus on, and do that. Try to understand what he thinks your role is, and do your best to fulfill it. It is possible that he needs you to do certain tasks so he can concentrate on the stuff he is doing. If you try hard to do the things he is doing, you might not be doing enough of your own task. Find your spot on the team, excel at that, and then expand. Tell him that you want to help out.

To my notion, the biggest asset a green programmer can bring to the table, beyond his existing technical skills, is initiative and passion. If you show your boss that you are aggressive about learning new things, aggressive about learning your way around the company, the code-base, the tools, and your co-workers, and you show that you have a passion for what you are doing, that will impress. Unless you're working for a horrible manager, in which case you want out anyway.

I would also suggest putting some focus on "soft skills" stuff. Demonstrate that you aren't just a geek who is useless in any sort of inter-personal interaction. Make friends with the people in sales, marketing, support, business development, project management, etc. Show that you are a good communicator and somebody who can work with people to get things done.

If you have the freedom to do so: Write grants, bring in some grant money from outside, or start a cooperation that has business value, with new partners that consider you a competent programmer or -at least- valueable employee.

Don't bother with impressing people or your bosses. Nobody is impressed by just talk.
Concentrate instead on shipping code. Ensure you are involved in projects or applications that will be used by people. More code you have in production more relevant you will be. More relevant you are to people more they will rely on you. Rest is all magic show.

Work hard. Do everything you're told and learn everything. You're very lucky to work under someone who knows a lot more than you, keep working until you can catch up.

In addition to working hard, and succeeding in the job you're in now, I'd like to give some advice that is maybe an answer to the question you're not asking. (It wasn't even on my radar when I got my first software job).

The internet is made by people like you. And people like you can make money on the internet.

Open up http://news.ycombinator.com and start reading the articles. You're going to see an endless wave of stories from people like you, who had an idea, built a website and managed to make a dollar or two doing it. It's inspiring and eye-opening there's a guy who earns a ridiculously good wage selling a bingo card generator to teachers... another guy who sold a website to google for millions. There's a lot of other interesting technology stuff in there too.

'Rich Dad, Poor Dad' there are places where he's got good advice.

'The Four Hour Work Week' take this one with a grain of salt, but he does have some interesting ways of looking at work & life.

Keep learning from the guy you're under now. There is so much to learn in 'your first real job' that I can't even begin. In the long run though (three, five, ten, twenty years) if you learn how to make your own money, you won't have to worry about impressing someone else.

I liked the story posted in the answer, but it's more entertaining than a reliable answer.

It's normal that everyone are just like you: trying to be better at what we do, that's human. But the horrible truth is that there are so little chances you will be the best at it.

Concerning myself, I always feared humility concerns, because I just hate those little childish fights about who's right and who's not, and here is why.

As long as you are not one of the best, you are better trying to work to get more experience comparing what you know and do to what best programmers know and do.

You could say I compare myself to the best programmers, but that's just half right:
- I'm better comparing myself to the best, knowing that I'm just ridiculous compared to them, so that makes the principle of comparing pretty stupid and useless
- I don't consider their fame but rather what they achieved to get it, because in reality, most geniuses myths fade away when you know true fact like how business works. It doesn't change the fact they achieved great work, but remember that experience is difficult to evaluate if you think about the working conditions.
- In the end, this process avoids the competition process which is really disturbing for me and help me focusing on what is important: learning by practice, but also learning with the help of a good curiosity engine.

You can admire somebody all you want, thinking he is so better than all other employees or other programmers you'll meet, but you have to remember that the world is vast and that the guy you admire is in fact quite average compared to other better experienced people there are out there, so maybe you'll feel better once you've impressed him, but you'll feel the same against other people with better experience than him, so it will be all for nothing.

Quit this petty game and try to find more interesting subjects you might have heard about, because this engineer you are talking about is certainly busy working for something less great that you're thinking.

I have to agree with some of the others here in that you are likely to fail in your objective -- because you are focusing on the wrong problem, or at least your focus is too narrow.

You want to be a great programmer -- does the subjective opinion of one software engineer bestow that title and ability on you (other than Joel)? If you focus only on impressing your boss then you are not concentrating on the work, or on improving your skills -- you are not focused on your goal of becoming a great programmer. You are trying to be granted respect rather than earning it.

Let's take the worst case (because programmers like to do that) -- your boss absolutely hates you for no objective reason (you wore a Patriots hat the first day, whatever). He's just never going to have a good opinion of you. If you concentrate on completing your tasks assigned, on solving problems efficiently and elegantly, and furthering your technical skill set -- you will improve yourself -- then in the end you are the winner -- independent of what your boss thinks.

Ashton job was a recipe for failure not because his code went unused, but because the job provided him with no practical benefit other than safety on Maslow's hierarchy. Was he learning new skills? No. Did his work allow him to be creative? No. Did it earn him respect? No.

Being that this is your first position, it will offer you most of these properties by default. You will have your first experiences programming professionally, you will be given new challenges both technical and non-technical. But there will come a time when you outgrow the position or it outgrows you, and you need to be continually improving yourself so you're not caught off-guard by it.

One more thing, if Ashton's going to measure his self worth merely by the amount of people using his code then I suggest he join a frequent-flier club. The only lasting happiness in life is that which we create for ourselves. Living strictly according to what other people's opinions of us are produces tragic and inauthentic human beings.