As a lone developer, how can I be sure I am learning and doing decent work? [duplicate]

Question

This question already has answers here:

Can a lone programmer become a mid or senior level programmer without a mentor? [duplicate] (4 answers)

Closed 5 years ago.

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.

EDIT:

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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)

3. Future value:

maintainability,

reusability,

portability

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

Answer 6

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.

Answer 7

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.

2. 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.

3. 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.

4. 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.