Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
What can I do to impress him?
Thank you.
Did I ever tell you about Ashton?
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.
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.
Do a good job at that and it'll impress the boss.
Two words: Be reliable.
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.
Write clear, solid code.
Knock on his door. Ask him if he has any shit jobs he's been putting off that you might be able to handle. Tell him to just fire you off an email later if he doesn't have time right now.
Read Knuth
(corollary: many people have Knuth, but no one reads Knuth)
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.
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.
thats about it i can share right now. ;)
Well, I just would add this quote from gospel:
"Whoever can be trusted with very little can also be trusted with much, and whoever is dishonest with very little will also be dishonest with much."
Having been a boss to programmers, I can tell you that nothing made me happier than when a programmer fixed a bug that I was to lazy to go fix!
So if you can, fix his bugs for him.
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".
Solve Rubik's cube. The boss will know that you like challenging puzzles and will give you tough assignments.
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.
@Mason is right
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.
Find something you're passionate about. Build it. Sell it. Be your own boss.
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.
You can rarely impress people by trying to impress them. And as long as you try to impress people, and they don't seem impressed, your frustration will grow.
Just do your job in a way that makes you proud of yourself. Don't worry about what anyone thinks. The only person you can make happy is you.
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.
