Startup Nugget #1: Multiple Responsibilities
As a developer, your work is structured, at least most of the time. A regular working day used to start by arriving at the office (remember?), getting your coffee, checking some emails, doing your daily standup where you get a grasp of what's going on for everyone during that day, you expose your work as well: what did I do yesterday, what am I doing today, what are my blockers. Then you sit in front of the PC.
Excepting some random occasions where a new project came along and you had to think about how to tackle this new problem, which architecture to use (most of the time better start with a monolith!), which tech to use (most of the time better start with something stable and easy to work with!), and you spent some interesting time with your colleagues in front of a whiteboard bouncing ideas, I'd say most of a developer's working schedule consists of opening your issues tracker and start either solving some bugs or crunching some new features.
Bugs tend to be quite easy to track down once you're acquainted with the codebase, and the kind of features I used to build in a corporate environment was less of "Implement a data transformation pipeline" and more "Render this table as a list with some extended data".
I have to give a shout-out to TenForce (https://tenforce.com/),
by far the best company I've ever worked with, where my colleagues
were the best and smartest, and in the project, I used to work in,
we had almost full freedom to use the tech, architecture, and structure
our code as we wanted. This situation was indeed possible due
to several factors aligning:
1. It was a project for the European Commission, so deadlines were
less strict than with a corporate client, despite being strict enough.
2. It was a microservices project, so for many features making a new
microservice was the weapon of choice, so as long as the language of
choice executes in the JVM (and you can find a compiler for java's
bytecode for **everything**) you were good to go.
3. My project manager at the time was a deeply technical dude, so he
had a very firm grasp of the complexity of what we were doing, and he
encouraged researching and testing things, but to embrace stable options
for commercial projects. I remember trying to make a Clojure microservice
work for a given task, and eventually, I had to drop it in favor of our
Python microservice template. I was obsessed with Clojure and he let me
play around at work with it.
So I'd say my work as a developer was comfortable with some high degree of predictability.
Now, as the co-founder of Websie, even though my skills are better put to use by writing code and thinking about what's the best way to implement business logic, there's a whole slew of activities that force me to context switch, although not every day.
Since I code most of my time, I still have some good old predictable targets: churn new features and solve bugs.
However, as it happens in a startup, roles tend to overlap, and even though in ours they are quite defined, I have found myself performing a set of different tasks not directly related to being a developer such as (in no particular order): minor marketing stuff, dealing with freelancers, writing tasks, managing a bit other developers, reading up on mental health startups to keep up with what's going on in the ecosystem, having meetings with potential partners to see how we can integrate the system and think about the user flow (more or a Product Owner thing).
I like going into the more human and organizational side of the business, as I love to learn more about equity, accounting, and managing.
So there's the nugget: in a startup, be prepared to have a very open range of responsibilities.
