Programming

Have you considered pairing up and doing end-to-end feature development together? That way you can learn from each other.

Being in a small company is different, but not worse (or better). With the roles you have on your plate already, you have a sprawling blank canvas to work from, and in a small company environment, you tend to have a significant amount of flexibility so long as you don't take your eye off of the main company objectives (vs a large company where "that's not your department" situations can squash many learning opportunities).

First, figure out what areas you want to focus on. This doesn't need to be forever, but you are going to need some degree of focus or you'll risk doing a hundred things poorly and not really learning much.

Once you've figured out what you want to focus on first and have done some basic research/discovery, seek a mentor. This is one place where small companies make things harder, as you almost always need to look outside to find mentoring.

With the Project Management and Cloud Architecture bits of your role, you can look at Financial Operations. Just make sure you take a high level look first to see if there's sense in that (make sure the ROI on you and your co-workers time plus any new services/providers needed makes sense for what you can potentially save - you want to be able to show that your time was well spent with any self-initiated project or you risk someone deciding that you need to be more closely monitored in the future).

With only 2 developers, CI/CD can be your best friend. Automate the daylights out of testing your code.

Remember to tag your regression tests in some way - any test that is preventing a production bug that actually happened needs to be marked as a 'regression' and treated as high priority to keep passing.

Treat all others tests as more art than science. Keep the reliable ones, toss out the brittle ones.

Look for a network traffic recording/replay library for your toolchain. Reusing integration tests as unit tests is a huge time savings.

If you have live data access, build yourself a few charts that represent a typical day. Knowing what "normal" looks like in your database can be priceless on a weird day.

We are all different, but what can be important is to make sure you keep exposing yourself to new ideas and concepts.

Ask to be allowed to go to a conference in which you can learn new things. There are frameworks and technologies out there you might not hear about outside of those places. Things that can potentially make an aspect of your job significantly easier and make the project easier to maintain. I learned about Factory Boy this way, and man does it help save time when building tests! https://factoryboy.readthedocs.io/en/stable/

Another aspect is if the scope grows - or the success of your project grows, so does the risk of being only two developers.

Make sure the business side understands this risk. If you or the other guy decides to leave they won’t find a good resource quickly and would need to rent a resource or go without for a while.

Also, make sure that you don’t let the fact that you like the job become a sleeping pillow for salary growth. The more responsibility you put on the more you should be paid.

I’ve been where you are, now I have six devs under me and a project lead. It’s been a though, but exciting journey.

The toughest part for us has been to push to transform the rest of the company into an organization that understands and cares about software development, and to take technical debt seriously.

In the beginning the business people were like “I like the funny words you say man”, they weren’t quite so entertained when we needed to spend a small year rewriting an app that got bit bad by technical debt. The interest payments were significant.

I've worked in a small org with very few devs. I was the only one for a while. I think the most important in this sort of environment is to care.

I've found it useful to pay attention to the org's goals and strategy as well as being interested in how operations work. This is because you may end up taking a ton of microdecisions during development and you want them to align. As your understanding grows and you slowly take your place, you may be consulted as well for all sorts of things.

You'll need to take your personal technical growth into your own hands. The org should be expecting you to do so and they may even grow interested in what exciting new stuff you've learned.

Also if you have plenty of non technical colleagues, translating your technical reality into layman's terms and in actual impact is key. It's important to build that bridge.

It can be a super rewarding experience! The fact you love the place and you're already wary not to stagnate makes me think you're a good fit.