7 ms·

My Experience Running Development at a Startup

182 points by antjanus 10y ago

mxuribe 10y ago
Excellent article! If no one else tells you: i appreciate the time you took out of your business to write this up. This is some really helpful advice. I have a full-time day job, and am trying to get my side business to launch as my only job...and I can certainly learn from experiences like the one you described. Keep on truckin' with these types of posts, and good luck to you!
- antjanus 10y ago
  Thank you! Some of these things seem so self-evident but they were hard lessons. I've come to understand that there are a lot of business practices that just don't make sense to me until I get bit in the ass by not following them.
mknocker 10y ago
The tracers over prototypes advice is a precious one. Having worked for small and large companies, once you have a functional prototype that has been built quickly, managers tend to be very reluctant to let you rewrite the prototype architecture to make it clean. Using tracers you can demonstrate small but important features to the persons involved in the project and when the project will be given the go sign you can work peacefully on the product's architecture.
- antjanus 10y ago
  Urgh, yeah. I've been burnt by the "prototype looks good enough" for a long time until I finally realized: I have to use assume I'll end up using it. A fellow developer mentioned to me on slack that he calls it a "probe" which is just so much more fun to say and use in conversation.
- nostrademons 10y ago
  I haven't really experienced this, also having worked at both small and large companies. At the small companies, most of the prototypes failed (which is the whole reason you're prototyping) and then the ones that succeeded usually got rewritten because everything got rewritten multiple times. At the large ones, the prototype exists to convince a VP that this avenue is worth pursuing, and then typically it's handed off to another team to actually do. Could also be because I've basically always had technical management, and the projects I work on tend to be fairly technical in nature (i.e. "can we do this?", not "the customer wants this by Monday").
  - antjanus 10y ago
    That might be the reason but it really depends on company culture, funding, and other aspects. I built an early prototype for our product in the first two months. Losing two months wasn't an option for a rewrite. Even if I could get it done in a month, it just didn't make sense. The prototype was "good enough" to the point where it stuck.
- jordanlev 10y ago
  I'm unfamiliar with the "Tracer" concept. Can you provide an example of one of these you've built? I'm specifically curious how it differs from a prototype... is it just a prototype of 1 feature in isolation with bare-bones design? Or some feature that is only triggered from an arcane terminal command? Thanks
  - tobych 10y ago
    Just chiming in here: in The Pragmatic Programmer it's called a "tracer bullet", not a "tracer". You'll do a lot better searching for discussions by using "tracer bullet".
    - jordanlev 10y ago
      Okay, thanks. Just curious to hear some actual examples of this from people who've used the technique.
- tnecniv 10y ago
  I had a friend who worked in product design. He says their analog was to never paint prototypes. For some reason, when they demoed painted versions to clients, they assumed they were basically done. It didn't matter how much actual work the design firm still had to do!
knowaveragejoe 10y ago
Minor typo here: "When we switched to ES2105"
- antjanus 10y ago
  Not a typo. It's a stage -10 spec, it's so far out into the future that no one has thought of it yet and the people to implement it haven't been born yet. :) thanks. I'm fixing it!
madaxe_again 10y ago
"CTO in training" Danger, Will Robinson! I followed a similar path to the one you now tread. I cofounded, and managed/grew the dev team from me to forty folks. Three years ago (after seven years of just "tech director"), I took the mantle of CTO. Error. CTO is not a technical role. To do it well, you must be technical, but it is in reality a sales and marketing role, both internal and external. I found myself isolated from our tech team in short order, as as CTO one is the public and board level technical face of the company - and that becomes all consuming, and you become the perceived source of all the problems. You become the messenger, who is much shot at, by both clients and your former allies in your technical team. The clients shout at you for bugs. The developers shout at you for pleading that bugs get fixed. You become that which lives between hammer and anvil. You are no longer part of the team. You are the boss. So - unless you want to get out of technology and want to work as a marketeer/apology bot, don't aim for CTO. I did, it broke me. I left my company today, as I started it for the love of tech, and making cool stuff - and at the point of organisational development they have reached, that is not something there's any scope for a CTO to do. Lesson learned.
- antjanus 10y ago
  Haha yeah, that's why I added that I don't really call myself that but it sounds better for the story. I'm basically a lead dev. I don't mind getting out of tech but right now, I'm here, and I enjoy the tech and I enjoy trying to get a project back on its rails and get to an MVP.
- nbclark 10y ago
  Sorry to hear this. I've been through a similar transition. 1 of 2 devs 5 years ago, growing a team to 45+ engineers today. I felt a lot of what you describe. I was somewhat aware of the split (as it was happening) between technical creativity and being the face of the team (but not actually building). I realized that building, being creative was something I didn't want to lose. I hired directors and promoted (eventually) one to VP. He and I work very closely, but the clear distinction is he runs the engineering team, and I am responsible for running the architecture group, facilitating engineering culture and leading research. Thankfully my CEO was supportive of the split I defined, and it has allowed me to not lose my identity. But for a good 2 years there, I was struggling to find the right fit. And as for getting yelled at about bugs, that's just part of the job. It's hard not to take personally, but when you realize that CSMs get yelled at so much more about bugs than we do in engineering roles, it helps put the pain into perspective.
xxr 10y ago
Your account of the state of JavaScript in this decade reminds me of this post from a few days ago: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
- antjanus 10y ago
  I'm actually not a big fan of that article :/ or rather, I disagree with it. I've been meaning to write my own piece on it. But the summary is: you can make it as easy or complicated as you want it to be. And I mean, every technology has the same issue. Take PHP for instance. Want to learn it? Cool, it's super easy. Want to build an app? Okay, so there these different frameworks. Oh btw, you should know about composer. And autoloading. Did you also hear about DI that Symfony uses? etc. etc.
- pbreit 10y ago
  This strikes me as the type of app that would be fine in Rails/Django and much, much easier to develop, maintain and enhance. I'd reserve Node/SPAs for 1) realtime or 2) UI/UX intensive. Landdox seems neither.
jpulec 10y ago
I was the first engineer hire at a small startup, and have helped our CTO/Co-founder grow the company over the past 3 years. All I can say, is that almost everything that was said here was the exact experience we had. Even down to the choice of Angular 1.X and rewriting all of the IIFEs in our codebase to use ES6 imports with babel. I also need to acknowledge that PM is something that you do fine with 2 people, but your processes will fall apart, probably as soon as you even hit 4 or 5 people.
leemac 10y ago
"For smaller projects like microservices, isolated applications, even parts of the UI that most users don’t see, experiment." I agree with this part 100%. We're still rocking BackboneJS that we chose in 2011 or so. Sure it's behind the times as they say, but it's rock solid for our uses. We're in too deep to convert now and the cost doesn't outweigh the benefits. Clients are happy and we're happy. In other newer areas, we're experimenting, mostly with RabbitMQ for small things on the backend and React Native on Mobile. With UI on new projects not in the core web app, we experiment. Works rather well and keeps us sane with the pace of JS frameworks.
nerdy 10y ago
The end of the article feels like a cliffhanger for a CI-CD sequel.
szines 10y ago
This article wouldn't be there if they choose the right tool for this job. Typically for big apps, with Ember.js, you never have these problems what he described.
Yhippa 10y ago
The amount of real-world experience you got from this I'm still trying to get. That to me is the value of being in tech at a startup. I enjoyed this article, thanks.
20years 10y ago
I like the Tracers concept. As for "everything is legacy a week later" - why not stick with boring but proven technology and frameworks for software that is crucial and you plan to have around for awhile? That may mean not using most of the JavaScript frameworks that are being pushed today. Sure, play with them for smaller or non business crucial stuff but why risk building a business on that instability? There are so many other important things that a business or startup has to focus on, spend money on, etc. I guess I prefer to put a lot of resources into those things vs worrying about having to update or re-write my tech stack every few months on the latest shiny framework.
- noir_lord 10y ago
  I picked knockout about 3 years ago because it seemed stable then, officially supported IE and had good docs. 3 years later I'm still using code I wrote against it (though now with browserify) with no changes. The switching cost when you can dump the old framework on every new project is much lower than the "This will be around for 3-7 years". Now I follow what is happening in the JavaScript community but I don't consider using anything until its been out a year and is still active/growing. Much of the churn seems to be throwing out everything for an incremental theoretical improvement, that rarely pays off in my domain.
pavlov 10y ago
Nice article. There's one paragraph that exposes a certain bit of web dev mindset that rubs me the wrong way: "Updating things as you go also means that parts of the application that get less love tend to be written with an older style [...] and using older technology (like indexOf rather than contains or a for loop rather than reduce)." That's not "older technology"! You're talking about whether to use some helper methods on Array.prototype. Who cares? It's certainly not any kind of technology choice. It's really no different from whether you prefer to put your opening curly brace on the same line as an if sentence or the next one. Sure, it's slightly annoying when someone does it differently, but you shouldn't spend any time bikeshedding your codebase over stuff like this.
- antjanus 10y ago
  You're completely right! I meant to say that some parts of the application are written in an older style that we don't use anymore. For loops, indexOf, etc. are valid and there's nothing wrong with using them, we just use a more functional approach now and use some of the newer methods for doing the same thing.
  - rajangdavis 10y ago
    I don't think this is necessarily a wrong thing; I feel like really ground breaking/challenging development forces you to understand what you are building the farther you go along. It's always ideal to have perfect code the first time it's written, my experience is that this is never going to happen unless you have perfected what you are building to the point that you have code generators/boiler plate code to cover most of what you are building. With that said, very interesting article. Thank you for sharing your experience, it is very eye opening for me.
fsloth 10y ago
"issues with Javascript today is the idea that we have to keep learning the latest technology and keep using it. " I don't get it. Why? For ISV it's the product that matters. ESP:s might as well invent filler to charge the client but what does it help in creating a product with JS to run after the bleeding edge? Usually we pick up a language and toolset, write the product with it, and if there are bugs that absolutely need to rearchitect some foundational things then then, only then is it worthwhile to ponder if some basic technical constructs need a major overhaul. This "update to latest hot as you go" sounds like velocity is lost in trying to adapt to some new gimmick for no benefit. Obviously there is some cost/benefit tradeoff here I'm not getting. What is it?

182 points by antjanus 10y ago

Excellent article! If no one else tells you: i appreciate the time you took out of your business to write this up. This is some really helpful advice. I have a full-time day job, and am trying to get my side business to launch as my only job...and I can certainly learn from experiences like the one you described. Keep on truckin' with these types of posts, and good luck to you!

antjanus 10y ago
Thank you! Some of these things seem so self-evident but they were hard lessons. I've come to understand that there are a lot of business practices that just don't make sense to me until I get bit in the ass by not following them.

mknocker 10y ago

The tracers over prototypes advice is a precious one. Having worked for small and large companies, once you have a functional prototype that has been built quickly, managers tend to be very reluctant to let you rewrite the prototype architecture to make it clean. Using tracers you can demonstrate small but important features to the persons involved in the project and when the project will be given the go sign you can work peacefully on the product's architecture.

antjanus 10y ago
Urgh, yeah. I've been burnt by the "prototype looks good enough" for a long time until I finally realized: I have to use assume I'll end up using it. A fellow developer mentioned to me on slack that he calls it a "probe" which is just so much more fun to say and use in conversation.
nostrademons 10y ago
I haven't really experienced this, also having worked at both small and large companies. At the small companies, most of the prototypes failed (which is the whole reason you're prototyping) and then the ones that succeeded usually got rewritten because everything got rewritten multiple times. At the large ones, the prototype exists to convince a VP that this avenue is worth pursuing, and then typically it's handed off to another team to actually do. Could also be because I've basically always had technical management, and the projects I work on tend to be fairly technical in nature (i.e. "can we do this?", not "the customer wants this by Monday").
- antjanus 10y ago
  That might be the reason but it really depends on company culture, funding, and other aspects. I built an early prototype for our product in the first two months. Losing two months wasn't an option for a rewrite. Even if I could get it done in a month, it just didn't make sense. The prototype was "good enough" to the point where it stuck.
jordanlev 10y ago
I'm unfamiliar with the "Tracer" concept. Can you provide an example of one of these you've built? I'm specifically curious how it differs from a prototype... is it just a prototype of 1 feature in isolation with bare-bones design? Or some feature that is only triggered from an arcane terminal command? Thanks
- tobych 10y ago
  Just chiming in here: in The Pragmatic Programmer it's called a "tracer bullet", not a "tracer". You'll do a lot better searching for discussions by using "tracer bullet".
  - jordanlev 10y ago
    Okay, thanks. Just curious to hear some actual examples of this from people who've used the technique.
tnecniv 10y ago
I had a friend who worked in product design. He says their analog was to never paint prototypes. For some reason, when they demoed painted versions to clients, they assumed they were basically done. It didn't matter how much actual work the design firm still had to do!

knowaveragejoe 10y ago

Minor typo here: "When we switched to ES2105"

antjanus 10y ago
Not a typo. It's a stage -10 spec, it's so far out into the future that no one has thought of it yet and the people to implement it haven't been born yet. :) thanks. I'm fixing it!

madaxe_again 10y ago

"CTO in training" Danger, Will Robinson! I followed a similar path to the one you now tread. I cofounded, and managed/grew the dev team from me to forty folks. Three years ago (after seven years of just "tech director"), I took the mantle of CTO. Error. CTO is not a technical role. To do it well, you must be technical, but it is in reality a sales and marketing role, both internal and external. I found myself isolated from our tech team in short order, as as CTO one is the public and board level technical face of the company - and that becomes all consuming, and you become the perceived source of all the problems. You become the messenger, who is much shot at, by both clients and your former allies in your technical team. The clients shout at you for bugs. The developers shout at you for pleading that bugs get fixed. You become that which lives between hammer and anvil. You are no longer part of the team. You are the boss. So - unless you want to get out of technology and want to work as a marketeer/apology bot, don't aim for CTO. I did, it broke me. I left my company today, as I started it for the love of tech, and making cool stuff - and at the point of organisational development they have reached, that is not something there's any scope for a CTO to do. Lesson learned.

antjanus 10y ago
Haha yeah, that's why I added that I don't really call myself that but it sounds better for the story. I'm basically a lead dev. I don't mind getting out of tech but right now, I'm here, and I enjoy the tech and I enjoy trying to get a project back on its rails and get to an MVP.
nbclark 10y ago
Sorry to hear this. I've been through a similar transition. 1 of 2 devs 5 years ago, growing a team to 45+ engineers today. I felt a lot of what you describe. I was somewhat aware of the split (as it was happening) between technical creativity and being the face of the team (but not actually building). I realized that building, being creative was something I didn't want to lose. I hired directors and promoted (eventually) one to VP. He and I work very closely, but the clear distinction is he runs the engineering team, and I am responsible for running the architecture group, facilitating engineering culture and leading research. Thankfully my CEO was supportive of the split I defined, and it has allowed me to not lose my identity. But for a good 2 years there, I was struggling to find the right fit. And as for getting yelled at about bugs, that's just part of the job. It's hard not to take personally, but when you realize that CSMs get yelled at so much more about bugs than we do in engineering roles, it helps put the pain into perspective.

xxr 10y ago

Your account of the state of JavaScript in this decade reminds me of this post from a few days ago: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

antjanus 10y ago
I'm actually not a big fan of that article :/ or rather, I disagree with it. I've been meaning to write my own piece on it. But the summary is: you can make it as easy or complicated as you want it to be. And I mean, every technology has the same issue. Take PHP for instance. Want to learn it? Cool, it's super easy. Want to build an app? Okay, so there these different frameworks. Oh btw, you should know about composer. And autoloading. Did you also hear about DI that Symfony uses? etc. etc.
pbreit 10y ago
This strikes me as the type of app that would be fine in Rails/Django and much, much easier to develop, maintain and enhance. I'd reserve Node/SPAs for 1) realtime or 2) UI/UX intensive. Landdox seems neither.

jpulec 10y ago

I was the first engineer hire at a small startup, and have helped our CTO/Co-founder grow the company over the past 3 years. All I can say, is that almost everything that was said here was the exact experience we had. Even down to the choice of Angular 1.X and rewriting all of the IIFEs in our codebase to use ES6 imports with babel. I also need to acknowledge that PM is something that you do fine with 2 people, but your processes will fall apart, probably as soon as you even hit 4 or 5 people.

leemac 10y ago

"For smaller projects like microservices, isolated applications, even parts of the UI that most users don’t see, experiment." I agree with this part 100%. We're still rocking BackboneJS that we chose in 2011 or so. Sure it's behind the times as they say, but it's rock solid for our uses. We're in too deep to convert now and the cost doesn't outweigh the benefits. Clients are happy and we're happy. In other newer areas, we're experimenting, mostly with RabbitMQ for small things on the backend and React Native on Mobile. With UI on new projects not in the core web app, we experiment. Works rather well and keeps us sane with the pace of JS frameworks.

nerdy 10y ago

The end of the article feels like a cliffhanger for a CI-CD sequel.

szines 10y ago

This article wouldn't be there if they choose the right tool for this job. Typically for big apps, with Ember.js, you never have these problems what he described.

Yhippa 10y ago

The amount of real-world experience you got from this I'm still trying to get. That to me is the value of being in tech at a startup. I enjoyed this article, thanks.

20years 10y ago

I like the Tracers concept. As for "everything is legacy a week later" - why not stick with boring but proven technology and frameworks for software that is crucial and you plan to have around for awhile? That may mean not using most of the JavaScript frameworks that are being pushed today. Sure, play with them for smaller or non business crucial stuff but why risk building a business on that instability? There are so many other important things that a business or startup has to focus on, spend money on, etc. I guess I prefer to put a lot of resources into those things vs worrying about having to update or re-write my tech stack every few months on the latest shiny framework.

noir_lord 10y ago
I picked knockout about 3 years ago because it seemed stable then, officially supported IE and had good docs. 3 years later I'm still using code I wrote against it (though now with browserify) with no changes. The switching cost when you can dump the old framework on every new project is much lower than the "This will be around for 3-7 years". Now I follow what is happening in the JavaScript community but I don't consider using anything until its been out a year and is still active/growing. Much of the churn seems to be throwing out everything for an incremental theoretical improvement, that rarely pays off in my domain.

pavlov 10y ago

Nice article. There's one paragraph that exposes a certain bit of web dev mindset that rubs me the wrong way: "Updating things as you go also means that parts of the application that get less love tend to be written with an older style [...] and using older technology (like indexOf rather than contains or a for loop rather than reduce)." That's not "older technology"! You're talking about whether to use some helper methods on Array.prototype. Who cares? It's certainly not any kind of technology choice. It's really no different from whether you prefer to put your opening curly brace on the same line as an if sentence or the next one. Sure, it's slightly annoying when someone does it differently, but you shouldn't spend any time bikeshedding your codebase over stuff like this.

antjanus 10y ago
You're completely right! I meant to say that some parts of the application are written in an older style that we don't use anymore. For loops, indexOf, etc. are valid and there's nothing wrong with using them, we just use a more functional approach now and use some of the newer methods for doing the same thing.
- rajangdavis 10y ago
  I don't think this is necessarily a wrong thing; I feel like really ground breaking/challenging development forces you to understand what you are building the farther you go along. It's always ideal to have perfect code the first time it's written, my experience is that this is never going to happen unless you have perfected what you are building to the point that you have code generators/boiler plate code to cover most of what you are building. With that said, very interesting article. Thank you for sharing your experience, it is very eye opening for me.

fsloth 10y ago

"issues with Javascript today is the idea that we have to keep learning the latest technology and keep using it. " I don't get it. Why? For ISV it's the product that matters. ESP:s might as well invent filler to charge the client but what does it help in creating a product with JS to run after the bleeding edge? Usually we pick up a language and toolset, write the product with it, and if there are bugs that absolutely need to rearchitect some foundational things then then, only then is it worthwhile to ponder if some basic technical constructs need a major overhaul. This "update to latest hot as you go" sounds like velocity is lost in trying to adapt to some new gimmick for no benefit. Obviously there is some cost/benefit tradeoff here I'm not getting. What is it?