Developer First as a company value
A couple of months ago Dor Sasson called me and asked if I minded joining him in his new startup.
I was waiting for an awesome opportunity like this one to present itself so I just went for it.
Earlier this month I quit my old job and joined remotely (as I am currently based outside Israel) to help build a company from scratch.
On one of the first days Dor said that one of our values is that we are building a “Dev (Developer) first” company.
Being me, my initial reaction was: “Sure, you say that now, but let’s see how this will fit in reality when we get to the painful trade off that every startup has — running fast with product features or investing the time building and refining our internal development tools. All while not having that many working hands yet”
For me, being “Dev first” means being “Dev first” both internally in the company we are building, and of course externally.
Being “Dev First” Internally means that we invest time in building good stable pipelines, processes and internal tooling to support top notch development experience (more about our dev top notch experience in later posts — work in progress).
Often, in early stage companies this is neglected in favor of what is perceived as “running faster”. Eventually, teams end up wasting lots of time doing manual work, having slow processes and pipelines are counterproductive to “velocity”.
Not only does it slow teams down, the quality of the product suffers tremendously. We might end up doing a lot of manual work which is prone to have something go wildly wrong.
Lastly, and not less important, developers become frustrated that pipelines and processes which can and should be smooth are really painful to work with.
Quite often those concerns will be dismissed because they are quite hard to communicate to non-tech colleagues and get the buy-in to invest the time to build the needed tools.
Being “Dev First” externally means that each external product we develop and ship is always developed as if it was one of our internal tools. We have to feel that it is a tool that we would love to integrate with.
That means that all our api’s will have out of this world docs, our sdk naming conventions and usability will be as flawless as possible and we generally invest effort to make the developers that integrate with us ecstatic about our dev tools.
Honestly, we just started building the company, and the following example is not that huge of a project, but I feel it’s a good example to showcase the “spirit” of how we want to work and approach those topics in our company.
A couple of days in, we started building our initial CI/CD pipelines. I honestly love that part where you build the infrastructure that allows you to fastly and reliably ship your products.
Currently, we are looking at a setup of one statically served from s3 front end service and one Nestjs backend service. We decided to go for GitHub actions for the CI part and use Octopus for the CD part.
Octopus manages the environment variables conveniently for us. One of the challenges we ran into is how to propagate the freshest snapshot of our environment variables easily from its store in octopus to a local .env file that can be used to run and develop our services locally.
Our possible solutions as we saw it are:
- Do it manually. We only have a couple of services — to begin with probably not more than 10 environment variables per service. A developer that wants to run it locally can just copy each var from the octopus ui and paste it in the file. Of course if a variable needs to be changed in octopus, it will need to be properly updated in the file.
- Invest some time building an internal CLI tool that will help us to automatically pull the most recent config from octopus and populate a local .env file. This option will allow us to have the freshest variable set copy when we work locally, avoid mistakes doing it manually and try to debug what we did wrong.
Option two means that we will invest some time developing this tool.
I was excited to present these two options to Anton Zagrebelny, our CTO, and the team to see how this “Dev First” value is interpreted. It took merely 30 sec to make the decision to get the green light and put it on our board for development. In quite a few of the other places I’ve worked this would be put down immediately, but in our company it was picked up happily.
I’m really happy to build this tool and really looking forward to building our next values and engineering culture together with this insanely talented team.
