Background: I work in a small (less than 75) person engineering/manufacturing company. I was hired as a developer to work with a single teammate, our purpose being to migrate the company to the modern digital age. My teammate however is not a developer, but instead an industrial engineer, who primarily works on broad ideas, planning, and other non-code related areas. I do all the development.

Problem: I enjoy my work, and it's (shockingly) low stress, probably due to the fact that pretty much no one understands what I do. This includes my boss, he hired me only knowing that he needed someone who can "code". The problem with this is that I am forced to solve every task myself, without any input from colleagues/seniors. I am very good at what I do, but also quite young (haven't even started college yet), and so I would have seriously benefited from having seniors to teach and correct me. Unfortunately this isn't possible at the current time, so I'm stuck doing everything my way and hoping it works out.

This works I suppose, except I have no way to know if I am doing things in a terrible fashion that will eventually cost me months of rework time. Am I doing things efficiently? And although I haven't run into this yet, what if I really just can't figure out a problem that blocks our project? I can't hand it off! And what about when I leave? What if the next developer grows to curse my very being because of what lays before his eyes? :)

These questions worry me quite frequently, and it brings me to my question:

As a lone developer, what can/should I do to make sure I am learning, and producing efficient, maintainable, and proper (near bug free) code. How can I do things like:

  • review my own code
  • review my own designs
  • etc.


My question is similar but not a duplicate of Can a lone programmer become a mid or senior level programmer without a mentor?, that question is about "ranking up" as an individual programmer, I am asking how I can make sure I am learning and doing things properly without any other technical oversight.

  • You could suggest to your boss to publish some of the code as free software. Then other people are able to review your code (and helping with it). However, don't do this without written permission. Commented Mar 30, 2015 at 13:18
  • 1
    If the systems you're developing are vital or will become vital for the company, then please make sure it's understood that having only one developer responsible for the code is risky. Risks could be even higher if the developer is very talented and productive.
    Commented Mar 30, 2015 at 15:15
  • 1
    Possibly related: programmers.stackexchange.com/questions/134541/…
    – Jaydee
    Commented Mar 30, 2015 at 15:57
  • 1
    okay, i clicked a few clicks and am looking at your resume now. looks like you did start college (Washtenaw) and you were home schooled (and it appears you were home-schooled well). you will benefit from some real Computer Science courses that are about deeper concepts than "just" programming. but judging from all of the languages you know, it appears to me that once the problem is outlined to you (by folks who don't know how to program), you have little trouble figgering out what tools you need to create a solution. perhaps it ain't the most optimal solution (due to youth) but WTF. Commented Mar 30, 2015 at 19:58

7 Answers 7


As a lone developer, what can/should I do to make sure I am learning,

There are books you can read.
There are user-groups/meetups where you can talk with other developers.
There is a code review site here where you can post code (that isn't vital/identifyable to your company) to get feedback.

These are all fine, but no substitute for good practice. In order to write good code, you're invariably going to have to write bad code first. The best thing you can do is be introspective about how the code is.

Is it painful to use? Is it fragile to extend? Do you seem to be doing the same things over and over?

That sort of iterative improvement is the key for growing - programming or not.

  • 1
    You (and the others) all have great answers, but I would add the possibility of going to school and getting a formal education. The company might even help pay for it. While that won't necessarily give you a lot of practical experience, it can help teach some of the concepts behind good architecture and design.
    – David K
    Commented Mar 27, 2015 at 12:37
  • @Davidk - It's not clear that Josiah doesn't have a formal education. And I would not recommend this. In my experience, universities are horrifically bad at teaching people to write good code.
    – Telastyn
    Commented Mar 27, 2015 at 13:14
  • He says "I am ... also quite young (haven't even started college yet)", but I won't argue with universities' ability to teach code, since I took a total of one programming class in college.
    – David K
    Commented Mar 27, 2015 at 13:43
  • @Davidk - ah yes, you are right. College is good, mostly for the degree. Though learning to program well isn't likely to be a result of it.
    – Telastyn
    Commented Mar 27, 2015 at 13:47
  • 1
    @DavidK - Formal education is definitely coming, see my profile though, I'm only a senior in high school right now. :) So although education is definitely important, this question is about learning without it.
    – Josiah
    Commented Mar 27, 2015 at 13:51

In addition to the other answers:

Participating on programming forums like StackOverflow, Programmers.SE and CodeReview.se can also help you. You could decide to spend a percentage of your time there. Studying is part of the job of being a developer.

Also, there's probably video's out there about new features in your programming language - those with people actually writing code examples. Even if you have no intention of upgrading your dev environment, you always see people doing things differently than what you're used to.

These are ways to stay in contact with other developers without actually meeting them.


You really want to get some input from other developers. Adding to what Telastyn and Kent have already suggested, contributing to some active open source project is a good way to get feedback on your coding style/efficiency.

Another thing to think about is what do you dislike (specifically) about your current language/tools. Chances are that some problem areas aren't really and are instead excellent places to improve yourself in.

  • 3
    When you develop some software at work which is useful for a wider audience, you might consider to suggest to open source some of your own software. This would attract other developers to improve it, showing you how you could do better. Many large tech companies are doing this. Details about how to do this well would be an interesting topic for the newly proposed open source stackexchange which is currently looking for committers so it can go into beta.
    – Philipp
    Commented Mar 27, 2015 at 8:20
  • Ah, yes. That is true. I actually am a contributor to Mozilla and have learned a lot there! I mostly did theme and front end stuff, which is pretty much the opposite of what I do at work, but I could start doing backend things at Mozilla. Thanks for the tip!
    – Josiah
    Commented Mar 27, 2015 at 11:45

It is good that you recognize your situation and are wanting to do things right. Some bad habits are hard to kick if you keep them for too long.

If there are developers on other teams at the company, see if you can join up with them to bounce ideas off of, and to have them look over your shoulder once in awhile.

Books, blogs, podcasts, local user groups and meet ups (as @Telastyn said) are all good sources of new ideas, as well.


How do I know if I'm doing things right?

it's never done, perfect, unable to be improved on. but it's still good to measure your work (which is code) according to some metric or metrics of performance. i sent you a powerpoint of something i presented in 2008.

there are some obvious metrics that i thought are salient:

Is this stuff you wanna do?

  1. Make cool product
  2. Uses your Intellectual Property
  3. Niche market (e.g. audio)
  4. Make money
  5. Expect to have a future:

a) Long term vs. short term interests

b) Leverage old into new

Does your code:

  1. Performs a cool function (that's the main idea)

  2. Cost:

required hardware

execution time (speed)

space (tight loops)

non-recurring (NRE)

  1. Future value:




Decide what's important, see how well your code scores with the goals you have for it.


The one tip I can give is read open source code.

Understand how leading codebases are structured and what coding styles and frameworks are used. That way you will not learn "into the wrong direction" and stay current with the industry for when you switch.


In my personal experience:

  1. Read open source code sounds great, but most of us rarely have the bandwidth to dive into projects. Especially with the kind of time that a project deserves. Without that kind of time one cannot always appreciate the whys behind the way code was written.

What i do now is- i pick up only modules of open source projects as a reference than starting from the beginning. Coding python and want to see how pros do logging or config? Pick up a project you have used. That familiarity fends off exhaustion. For me it was Graphite's carbon daemon.

  1. While good mentors are good, bad ones are really bad.

It is actually a rather freeing being a lone developer, as you get to pick your influences. They can be the best in the world. If you are the only dev, the job is most probably not as stressful as one in which the fastest coding monkey gets the banana. Pick up Code complete 2, The unix programming environment, 97 things every programmer should know. You are your limit. This can be both liberating and intimidating.

  1. A "xyz best practices" on stackoverflow combined with the top five on a google-search is for most practical cases- better than any mentor around you.

It is more common to find bad mentors than good ones. And even the good ones won't be the utter best at everything across the board. They will have their limitations, biases. Top voted answers would not. Make it a point to subscribe to the Newsletters of code-review and programmers.se. And if you can afford to go through the comments on relevant threads on HackerNews, i don't think any team of mentors can beat this.

  1. Low energy barrier to newer tools.

You don't have to convince a team to move from svn to git. Stick around HN and you can be as good as good gets.

All said, your biggest obstacle is the size of your project. As rightly mentioned in answers above, you have to write bad code. You arrive at good coding practices.

Things i could never make-up-for:

In teams that pivot frequently because of the mgt, the code itself is revelatory in the sense that you can eventually see what's wrong. When you have-to bend your code for different use-cases, you 'see' what breaks. In general programming with fixed requirements, this flexibility is rarely demanded which allows room for hardcoding, bad design, a short sighted procedural approach.

  • The good thing about reading source code in my opinion is that you can pick interesting projects. For example anyone wanting to learn C++ should read the DOOM 3 source code. It's fun to read gaming code and some of the most beautiful C++ in existence.
    – MrDosu
    Commented Apr 1, 2015 at 12:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.