Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am working on a software project where I am the only developer. I was an employee for 3 years, working with team 3 to 5. Then, everybody left and so did I. I continued to do some contract work for the company. I have stepped my toes in another company as a junior contractor (started writing Java, my professional employment revolved around PHP webshops), and left because I didn't fit in that well.

I couldn't get them to guide me when I needed it, instead, my PR's were rejected saying: "Don't see any value", or "This feature is incomplete and undocumented". Also, when I did specify in my comments "Feedback appreciated", I felt that my work was nitpicked way more than of their own, which I saw as double standards. In the end, my self-esteem went down a lot, I couldn't keep working with them and left. I got back to my previous contract work where I experiment and continue working on the same project (PHP), working on an old legacy system that needs improvements. How do I keep learning and continue work as a sole developer? One way is to learn from books, but I realize learning from smarter people has tremendous value.

At the same time I feel that maintaining a live legacy system can contribute to my experience improving the existing projects and provide value for the company (bugfixes, refactoring and improving stability).

I'd appreciate an opinion on that.



That's the catch - you don't improve as a sole developer. You can learn a lot, but actual improvement requires feedback.

I advise you to start collaborating to Open Source projects, don't be shy. Everyone is welcome and I've personally found OSS devs to be a friendly bunch(exceptions always apply though). That will be very valuable feedback from people of different levels of experience and people in different positions. Leverage this feedback to improve yourself, but be ready to flush your pride down the drain.


That's the catch - you don't improve as a sole developer. You can learn a lot, but actual improvement requires feedback.

Feedback can also come from "oh, that doesn't work as well as I'd expected".

Feedback from other people is usually faster and more efficient (so I agree with the recommendation), but isn't the only game in town.


Of course you can improve on your own.

If I come back to my own code a couple of months later, and it isn't immediately obvious how its working, then its a good time to refactor it and think about what you would have expected to make it more obvious. My code gets better as a result.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: