I'm the .1x programmer at my company. How can I best contribute? [closed]

Question

I work at a newly-minted startup of five people. We have a Ph. D in machine learning, a former member of the RSpec core team, and the guy who compiles the Git binary for OS X. That's just the employees; the founder has a Ph. D and was CTO for a multi-billion-dollar corporation before leaving to start a (successful) startup, and has now left that to start this one. We also might get a guy with a Ph. D in math.

Aaaaaaaaand then there's me, college-dropout intern. I think I'm pretty smart and I'm reading non-stop, but the delta of experience, skill, and knowledge between me and my co-workers is just breathtaking.

So put yourself in their shoes: you've got a bright young intern who has a lot to learn but is at least energetic. What would be annoying? What use would you hope to get out of him in the here and now? What would be pleasantly surprising if it happened?

Answer 1

Most important thing:

Don't be impressed by the titles. In a short time, you will realize that your Ph. D coworkers, too, are just humans. And some people with a Ph. D never really created anything practically usefull. Always remember that, don't feel inferior.

What I'd expect of you? To write good code and get things done. Chances are that you are someone who is really working, as you describe yourself as energetic. I've seen lots of people with degrees who took like forever to achieve simple tasks because they were focussing too much on details etc. Put that to good use and deliver good code in a reasonable time and soon everyone will respect you.

But don't disrespect the others. They're most likely older and you can probably learn valuable things from them. But don't take anything over mindlessly. Always try to understand and think for yourself. I'd expect you to copy the behaviours and knowledge from them that really work.

Answer 2

Humility goes a long way

With your humble attitude, I seriously doubt you'll be annoying. Humility goes a long way. (This is true for hot-shots as much as for interns.)

If your role is explicitly to support the others, you can be sure of being useful by simply asking. "What annoying task can I take off your plate?"

Another thing you'll find is that most people love to feel appreciated. If you truly look up to your team members, you can get away with asking them a lot and learning a lot from them. They'll feel flattered, but it will be genuine. It will also help you learn and become more useful.

Lastly, knowing less than them may be useful in itself. For example, you'll likely be better at writing documentation for APIs, because you'll ask the questions outsiders would ask, but which seem too obvious to the others.

And who knows? You may find that by being servant-minded, you become a leader.

Answer 3

You got a lot of good answers already. I think I can contribute by sharing my experience in a similar position.

Background: I'm working part time in an R&D department of a rather big company since a few years while my main occupation is studying CS. The people I work with most of the time have Ph.Ds or Master's degrees in EE, CS, Math and Physics. I started as a complete noob but learned a lot in those few years.

What would be annoying?

1. Asking questions that I could easily answer myself using Google
2. Interrupting others too frequently by asking a question. If you have a question that is not a blocker, do some other work until you can ask your question without interrupting the person you ask. You may collect a few questions and then ask for the time of the other person or wait until the person asks you about your progress or for a good time to go talk to him, e.g. when he was already interrupted by a phone call, at the end of a break,.. Then tell him "I did this and that, but currently I'm stuck here and there".
3. If you do get stuck (after exhausting google, and other resources), make sure you ask for help. Nothing worse than finding out someone's been stuck for 2 days on something you could have solved for them in 5 minutes (by Neil White, in the comments)
4. Don't try to be smarter then everybody else.

What use would you hope to get out of him in the here and now?

1. Do things that others find easy/annoying in a way that actually helps the team. That's really all of it.

What would be pleasantly surprising if it happened?

1. That you do most of your work in a satisfying way and get involved in the team's work more and more.

A few more tips:

1. Be humble.
2. Show interest in the work of the others.
3. If they explain something to you, make sure that you understand. If you don't, ask them to explain it in a way so that you get the basic idea at least.
4. Be reliable. Try to do the work as good as you can.

Answer 4

Good advice from others thus far. To answer your specific questions:

• What would be annoying?

It would be annoying if you asked questions without doing your homework first. Asking for help after doing what you can to solve the problem first is fine. But if someone is able to find the answer via a simple Google search or by perusing the manual, then it's annoying.

• What use would you hope to get out of him in the here and now?

I assume that you have some sort of project/assignment already. I'd hope that you'd be able to finish this with minimal supervision.

• What would be pleasantly surprising if it happened?

One pleasant surprise would be if you finished your work early. Then you'd be able to work on more projects with increasing complexity which would prove your reliability. Another surprise would be if you are able to anticipate the needs of the team and work on fulfilling them on the side. Does your team need an automated build environment, automated testing framework, specific computer/network configurations for testing, etc? These may be peripheral thing

Answer 5

Short Answer: Find out what the team needs, and perhaps what you like best, and work toward providing that.

Longer answer: In the early stages of a start-up, most of the time, all work is "up for grabs"; whatever tasks need to be done or tasks that people want to do are available to all takers. Your preferences can literally shape the direction that the company goes.

Interested in HR? Take over the hiring tasks. Or maybe do the payroll. Interested in programming? Find out what language the team wants to use. Try writing some unit tests for some of the code. Hate writing reports? Then don't. See if you can delegate that task to someone else and work toward a constructive solution. Take a bit of time and think about what you might want to do, then try it out.

One thing to keep in mind that when it comes to very small early start-ups, there's much more to do than just programming. If you want to code, great! If you'd rather do something else, that's good too! Learn fast, ask lots of questions and challenge yourself.

Answer 6

I'm not sure how helpful my answer would be, but I've been were you are now. Surrounded by people who I felt/knew had so much more to contribute than I would ever have. How to act in this position? Enjoy it rather than suffering. Instead of thinking how much you don't know, think about what you stand to learn and experience together with these people. Use them as a resource, be respectful and try to glean off them any piece of information and experience - become a sponge...

Now, this doesn't mean you have to stop trying to do things, but when you do, try to get them to look over your shoulder and review your work as you go. Try to complete a piece of work and then listen to what they have to say about it - write down the comments they give you and try to implement them to create better code. Don't be afraid to ask questions, just be respectful and try to ask good questions - try to absorb the data and consider your immediate question before asking - maybe the answer was already supplied... The best people love to teach, and I bet they would be glad to share their knowledge and philosophy of life with you.

In my situation I tried to do that, and whenever it worked for me, I was the happiest, I never understood why they kept me on, but I had the greatest time, and I like to think I became a better programmer and even man as a result of this experience.

All this is not to say you should underestimate yourself - you probably are much better than you give yourself credit for, but as people wrote here, titles and degrees aren't always that impressive in real life situations and humility goes a long way. So be respectful of everyone, listen, absorb - but take your own lessons from the experience - sometimes you are better off learning what not to do.

Good luck.

Answer 7

There is already a lot presented here, so I won't repeat what has been said.

At a quick glance it seems to me that you have experts and a leader with management skills/ideas. That is good, but it is incomplete.

You are the pragmatic one: make their lives easier.

There are at least two areas you can cover:

• delving deep into the technical details of the language the startup elected
• improve the quality of the code, and smooth the rough corners of working with it

---

Technical

Those guys are experts in their fields, and this is good, but it does not mean that they know how to code their way out of a paper bag. Honestly, I have seen very bright people writing horrid unmaintenable code.

You have the opportunity to become the technical lead here. Learn the language inside/out, until you know all its subtleties. Learn the idioms the community use. Research the useful libraries that exist out there.

---

Quality

There are ungrateful, but useful tasks:

• who maintains the code source repository ?
• who writes/maintains the tests ?
• who monitors that the test-suite pass ? and identifies the guilty commits ? and ping the offenders relentlessly ?

There are some steps that help, whether very formal or not:

• how do you review the commits ? (is there an ownership associated with some areas of the code ?)
• how do you plan the work/tasks ?

There is a lot of peripheral activities around having ideas and writing code.

You have the opportunity to become the quality lead here. Learn the industry best practices (bit of "Agile", bit of scrum, bit of TDD, ...), and compose a process that fit your company. Learn build systems (make, cmake, ninja, whatever), and write the scripts that make building/deploying easy. Check on Jenkins (or whatever) and build a continuous integration server.

---

They are impressive in their respective domains and that is great. Since at the moment you are non-specialized, I would say it's time for you to identify the weaknesses (you may ask for their opinions too) and fill a(the) gap(s)!