6 ms·

I used to work for a Startup considered by many as tech company. Our devs cared a lot about code quality, visited meetups, engaged in the community etc. devs us

by baxtr 7y ago

I used to work for a Startup considered by many as tech company. Our devs cared a lot about code quality, visited meetups, engaged in the community etc. devs usually stayed for at least 3-5 yrs. In contrast, there was a company that almost did the same business as we did. But, they were what people would have called a sales company, not a tech company. Decisions were based on sale opportunities, only. No one gave a shit about code quality, devs didn’t stay long and often were frustrated when they applied at our company. Which one was more successful? Unfortunately they were... we were often slowed down by discussions about code quality, ways of working, ethics and disrespect for revenue driven decisions. Maybe it was just an exception? But since then I have become skeptical when I hear about “tech” companies. I feel we nerds need to be value driven, too, and not die in beauty.

afarrell 7y ago
> Disrespect for revenue-driven decisions I think thats the one that hurt you the most. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... Code quality and developer experience matters because it enables you to quickly use a codebase to solve business problems. But you still have to focus on business problems.
- mannykannot 7y ago
  A professed concern for code quality sometimes manifests itself in endless bikeshedding over small matters. At least initially, be a little bit skeptical of the person with one system behind him, who is determined to do this one right.
ChuckNorris89 7y ago
Indeed, this matches my experience exactly. Your developer driven company may have great code quality and employee satisfaction but unless it has a FAANG-like niche all to itself, it will easily be beaten by the revenue driven agile sweatshop next door despite its low quality code and high turnover.
Silhouette 7y ago
It's an unfortunate reality that sometimes good is the enemy of good enough. I do think it's easy to go too far the other way, though. You can plan to throw one away. You can write a quick and dirty MVP. You can throw money at the scalability problem if you're lucky enough to have it. Sooner or later, though, you are the player with the established offering. Unless you want to keep rewriting it from scratch every few months, at greater and greater cost as your offering grows, you need decent code at that point to maintain reasonable progress in supporting whatever your next revenue-driven features might be.
codingdave 7y ago
Both of those styles of company focus are often beat out by companies that consider themselves to be customer service companies. A sale is step one, then you deliver the great customer experience which they actually signed up for. Development is a tool to improve that experience. But the company itself is delivering a service... that happens to be tech-based.
duxup 7y ago
>disrespect for revenue driven decisions That caught my eye as well. There's such a fine line to walk there where you avoid bad decisions "because customer X wants it" and recognition that giving the customer what they want is what you are there to do / what sells. I just had a discussion that was "We're not going to do this how they want as that is too wonky / would send the code in all sorts of strange directions ... but we're still going to give them what they want in spirit." If we had just said no, or blown off the sales guy's POV, probabbly lose a lot of traction with that customer.
- dasil003 7y ago
  The reality is that both engineers and sales have their own respective forms of myopia. Engineers often bias towards elegant code and architecture, salespeople bias towards whatever the last sales lead said on the phone. Both have some value, but neither one will unlock a massively scalable market. To do so you need some vision beyond what the sales lead is saying on the phone or what is easy to design elegantly. Not just that, but you also need rapid iteration and not to fall so in love with your early thinking that you can't effectively capture new insight along the way.
fbr 7y ago
IMO you are mixing 2 different things. 1. The business and product 2. The engineering quality You can have a tech company (business level as described in the article) and produce ugly code (ex: facebook?). You can sell groceries on the internet and have great code.
mharroun 7y ago
Rant time.. Revenue and business impact are ALL that matter. Good, clean, scaleable, and testable code only exist to rapidly support the above. The moment you choose tech value over buisness you are a risk not asset to a company. I sware sometimes I see so many delusional software "engineers" who care more about building technically excellent systems that are either delivered late or dont solve a/the real problem... it disgusts me.
- achillesheels 7y ago
  It likely comes from the fact engineers would rather build than sell, except selling is part of the iterative process! (The most crucial part as it obliterates wishful thinking on what the market needs)
- crispyambulance 7y ago
  > Revenue and business impact are ALL that matter. Sure, but only until your up-and-coming competitor eats your lunch because everything got taken over by a-hole MBA and PMP-types, everyone cool leaves, and the only people doing the work are disinterested consulting companies charging you through the nose.
  - ChuckNorris89 7y ago
    Your statement only applies for the FAANGlike companies/monopolies form SV working on the latest AI thingamajigs where they have enough AdSense/VC funds to support costly talent without worrying about making money. Everywhere else around the world software development is just a SCRUM powered meet grinder where if you don't sprint fast and cheap enough your competitors will eat your lunch.
  - lmeyerov 7y ago
    Unless the the startup already nailed the startup part and is at $5-10M/yr or will flip with 0 revenue, you have no lunch to be eaten, just aspirations. Your biggest competitor is your internal non-business efforts that distract from experimenting with what gets people to pay in a repeatable way. Only after you have built a working revenue machine -- which (depressingly) can simply be VC revenue and hoping the music doesn't stop -- do you have a lunch to worry about. Luckily, as Twitter and friends show, once you have made that lunch, you can turn even the biggest Ruby fail whale and php ball of mud into engineering for scaling & doing tiny feature iterations. Unfortunately, shiny engineering won't solve drastic product market fit iterations, and consumes the limited time & $$$ for achieving it. That's a lot of otherwise good habits and instincts to unlearn for engineers who never really had to go from idea to paying end users and instead needed to ride an existing monopoly and not break it: FANG, bigco, bank, consultants, etc. In a disturbing sense, a small # of new grads can fit in better on a startup team than a loud FANG cohort b/c most know how to do a bunch of small projects without being distracted by post-growth table stakes. (And you avoid the former-consultant "don't care about the end-customer, just the boss/politics" problem b/c of passion for the startup's mission vs. the tech.) I've come to appreciate either: Team 1: Staying tiny with people who demonstrably get that or are otherwise mission-focused (vs. tech-focused) until you do hit growth, Team 2: Or massively over-fundraising and over-hiring (with high risk of fast death) simply to deal with sales/marketing/engineering that is only at say 10% efficiency of Team 1
GrumpyNl 7y ago
Im gonna use this in quotes "I have become skeptical when I hear about “tech” companies. I feel we nerds need to be value driven, too, and not die in beauty." Thanks.
metalgearsolid 7y ago
If it makes you feel any better, I worked at the "sales company" and they certainly aren't winning big. I think you're just underestimating the amount of factors involved in determining business success.
hotdeo 7y ago
I had a first time similar related experience with a startup in Tokyo. The company was focused on IoT related projects and started by purely business oriented individuals with not much tech experience. Their strategy was to hire as many "foreign" engineers to focus on the development while they push out for investment and business opportunities. Unfortunately, there was an internal clash between the engineers and the business side over code quality vs just pushing some buggy IoT related application into production which led to over half the engineering team quit in under 6 months I being one of them. Somehow though they are still afloat a year after using the barely working buggy app that we finished before we left.

by baxtr 7y ago

afarrell 7y ago

> Disrespect for revenue-driven decisions I think thats the one that hurt you the most. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... Code quality and developer experience matters because it enables you to quickly use a codebase to solve business problems. But you still have to focus on business problems.

mannykannot 7y ago
A professed concern for code quality sometimes manifests itself in endless bikeshedding over small matters. At least initially, be a little bit skeptical of the person with one system behind him, who is determined to do this one right.

ChuckNorris89 7y ago

Indeed, this matches my experience exactly. Your developer driven company may have great code quality and employee satisfaction but unless it has a FAANG-like niche all to itself, it will easily be beaten by the revenue driven agile sweatshop next door despite its low quality code and high turnover.

Silhouette 7y ago

It's an unfortunate reality that sometimes good is the enemy of good enough. I do think it's easy to go too far the other way, though. You can plan to throw one away. You can write a quick and dirty MVP. You can throw money at the scalability problem if you're lucky enough to have it. Sooner or later, though, you are the player with the established offering. Unless you want to keep rewriting it from scratch every few months, at greater and greater cost as your offering grows, you need decent code at that point to maintain reasonable progress in supporting whatever your next revenue-driven features might be.

codingdave 7y ago

Both of those styles of company focus are often beat out by companies that consider themselves to be customer service companies. A sale is step one, then you deliver the great customer experience which they actually signed up for. Development is a tool to improve that experience. But the company itself is delivering a service... that happens to be tech-based.

duxup 7y ago

>disrespect for revenue driven decisions That caught my eye as well. There's such a fine line to walk there where you avoid bad decisions "because customer X wants it" and recognition that giving the customer what they want is what you are there to do / what sells. I just had a discussion that was "We're not going to do this how they want as that is too wonky / would send the code in all sorts of strange directions ... but we're still going to give them what they want in spirit." If we had just said no, or blown off the sales guy's POV, probabbly lose a lot of traction with that customer.

dasil003 7y ago
The reality is that both engineers and sales have their own respective forms of myopia. Engineers often bias towards elegant code and architecture, salespeople bias towards whatever the last sales lead said on the phone. Both have some value, but neither one will unlock a massively scalable market. To do so you need some vision beyond what the sales lead is saying on the phone or what is easy to design elegantly. Not just that, but you also need rapid iteration and not to fall so in love with your early thinking that you can't effectively capture new insight along the way.

fbr 7y ago

IMO you are mixing 2 different things. 1. The business and product 2. The engineering quality You can have a tech company (business level as described in the article) and produce ugly code (ex: facebook?). You can sell groceries on the internet and have great code.

mharroun 7y ago

Rant time.. Revenue and business impact are ALL that matter. Good, clean, scaleable, and testable code only exist to rapidly support the above. The moment you choose tech value over buisness you are a risk not asset to a company. I sware sometimes I see so many delusional software "engineers" who care more about building technically excellent systems that are either delivered late or dont solve a/the real problem... it disgusts me.

achillesheels 7y ago
It likely comes from the fact engineers would rather build than sell, except selling is part of the iterative process! (The most crucial part as it obliterates wishful thinking on what the market needs)
crispyambulance 7y ago
> Revenue and business impact are ALL that matter. Sure, but only until your up-and-coming competitor eats your lunch because everything got taken over by a-hole MBA and PMP-types, everyone cool leaves, and the only people doing the work are disinterested consulting companies charging you through the nose.
- ChuckNorris89 7y ago
  Your statement only applies for the FAANGlike companies/monopolies form SV working on the latest AI thingamajigs where they have enough AdSense/VC funds to support costly talent without worrying about making money. Everywhere else around the world software development is just a SCRUM powered meet grinder where if you don't sprint fast and cheap enough your competitors will eat your lunch.
- lmeyerov 7y ago
  Unless the the startup already nailed the startup part and is at $5-10M/yr or will flip with 0 revenue, you have no lunch to be eaten, just aspirations. Your biggest competitor is your internal non-business efforts that distract from experimenting with what gets people to pay in a repeatable way. Only after you have built a working revenue machine -- which (depressingly) can simply be VC revenue and hoping the music doesn't stop -- do you have a lunch to worry about. Luckily, as Twitter and friends show, once you have made that lunch, you can turn even the biggest Ruby fail whale and php ball of mud into engineering for scaling & doing tiny feature iterations. Unfortunately, shiny engineering won't solve drastic product market fit iterations, and consumes the limited time & $$$ for achieving it. That's a lot of otherwise good habits and instincts to unlearn for engineers who never really had to go from idea to paying end users and instead needed to ride an existing monopoly and not break it: FANG, bigco, bank, consultants, etc. In a disturbing sense, a small # of new grads can fit in better on a startup team than a loud FANG cohort b/c most know how to do a bunch of small projects without being distracted by post-growth table stakes. (And you avoid the former-consultant "don't care about the end-customer, just the boss/politics" problem b/c of passion for the startup's mission vs. the tech.) I've come to appreciate either: Team 1: Staying tiny with people who demonstrably get that or are otherwise mission-focused (vs. tech-focused) until you do hit growth, Team 2: Or massively over-fundraising and over-hiring (with high risk of fast death) simply to deal with sales/marketing/engineering that is only at say 10% efficiency of Team 1

GrumpyNl 7y ago

Im gonna use this in quotes "I have become skeptical when I hear about “tech” companies. I feel we nerds need to be value driven, too, and not die in beauty." Thanks.

metalgearsolid 7y ago

If it makes you feel any better, I worked at the "sales company" and they certainly aren't winning big. I think you're just underestimating the amount of factors involved in determining business success.

hotdeo 7y ago

I had a first time similar related experience with a startup in Tokyo. The company was focused on IoT related projects and started by purely business oriented individuals with not much tech experience. Their strategy was to hire as many "foreign" engineers to focus on the development while they push out for investment and business opportunities. Unfortunately, there was an internal clash between the engineers and the business side over code quality vs just pushing some buggy IoT related application into production which led to over half the engineering team quit in under 6 months I being one of them. Somehow though they are still afloat a year after using the barely working buggy app that we finished before we left.