8 ms·

I was looking around recently, particularly at startups, but then chose to stop. Here is my reasoning: * I am currently employed with great benefits. If I am g

I was looking around recently, particularly at startups, but then chose to stop. Here is my reasoning: * I am currently employed with great benefits. If I am going to throw that away there needs to be something of value in exchange: leadership position, architecture, or some other increase of responsibilities. I wasn’t seeing this. * If your primary platform or language is JavaScript everybody wants a tool jockey. They claim to want somebody full stack. But when you really press for details the really want somebody to do react on the front end and play around with their cloud provider. The services piece in the middle is where things get strained in a full stack interview. If tools are the direction of work I have already lost interest. Why would I want to give up stable employment with great benefits to wire tools together? I would rather just stare out the window. * The idea of a senior engineer is incredibly convoluted. It sounds like people want somebody who can mentor in a vacuum. You can only mentor so much about dicking around with tools. If you try to mentor past that and the culture is just go dick around with tools you are either mentoring too much or not enough. Either way you are a horrible senior incompatible to the new organization. Worse is when they ask you to guide and train junior developers without leadership support. Really if that should work beyond vague hints you need a title. Excellent juniors have a passion for learning but many juniors aren’t excellent, just want a paycheck, and feel insecure when challenged. From going through the exact same conversation several times in a row I get the impression many employers kind of know what they want to build, kind of guess at what they need, and completely guess at what qualifies as execution planning but cannot put any of that together into a single vision.

jitl 5y ago
What do you mean by “tools”? Generally I think of “tools” as anything that assists you in building, deploying, or operating a (production) service, but not the service itself. For my definition, the firebase CLI is a tool, but Google Cloud Firestore (a no-SQL data store) is not. At the places you talked to, was everything service-y left to a separate back-end/infra team?
- austincheney 5y ago
  By tools I don’t mean your OS or IDE. I mean those things so you don’t have to write code beyond a couple of figurations or text content.
  - adaml_623 5y ago
    Can you give examples. I'm not clear on what you mean
    - austincheney 5y ago
      * State management in the browser. This is stupid easy. I even wrote about exactly how to do this: https://github.com/prettydiff/wisdom/blob/master/state_management.md https://github.com/prettydiff/wisdom/blob/master/state_manag... * Just about anything to do with the DOM. Its a standard tree model. You learn it and get comfortable with it and suddenly all that browser tooling you cannot live without becomes immediately unnecessary. Hiding from this, making a bunch of excuses, and complaining about how hard life isn't appealing. * The file system is also a tree model. If you have an abstraction layer that normalizes file system access cross OS all you really need is a basic comfort of data structures. * Tools that provide session management are there because planning for real time parallel distribution is challenging. This is yet another one of those that once you go through it a few times you just know how to do it.
    - deleted 5y ago
      [deleted]
    - vincentmarle 5y ago
      I guess he/she doesn’t want to write glue code, but solve actual problems in code.
    - TheHegemon 5y ago
      Looking at the code examples they shared it seems like they are the lone-wolf sort of developer that wants to "solve problems" in code that no one else can read.
TameAntelope 5y ago
Regarding your second point, I think it's good to know what interests you, but there's a lot of quality ideas out there that don't have hard tech components, and if they invent hard tech problems to keep their engineers interested, they're probably not going to last very long. IMHO, the "all JavaScript tech stack, connected together by a cloud provider via tooling" pattern is probably among the faster ways to get an idea from inside someone's head and in front of customers, all of the longer term problems aside. To me personally, the "challenge" comes from being able to do all of that quickly and seamlessly, basically solid execution becomes the fun part. Oh, also I would love to make a bunch of money relatively quickly. :)
- handrous 5y ago
  IMO the only way to make that stuff engaging is to move "up" a level and be the one picking the tools to solve the problem, interacting with users/clients, that kind of thing. Basically, start your own business or become a product manager at a place where product manager is a fairly expansive role. Otherwise, I agree, it's all of: fucking boring; frustrating; and unrewarding. But, it's also most of the market for developers. :-/
- austincheney 5y ago
  The business should be inventing the problems, because that is (hopefully) driving the revenue that keeps you employed. Usually the business has all kinds of wonderful ideas of which some are practical and vetted while others are a distraction. If you are thinking in terms of automation, internal training, and service fulfillment you probably aren't properly aligning solutions to expense reduction. The benefit of writing original software is innovation and IP (even if open source and liberally licensed) that can generate additional revenue for the business. If you current approach is entirely dependent upon tools it will be boxed in to a set of configurations and flexibility is lost. From what I have seen on HN the greatest challenge for most early stage startups is finding product-market fit, which means you need to pivot at a moment's notice. That ability to pivot is far more significant than whether you can have a website up in 2 days versus 2 weeks.
  - 5y ago

jitl 5y ago

What do you mean by “tools”? Generally I think of “tools” as anything that assists you in building, deploying, or operating a (production) service, but not the service itself. For my definition, the firebase CLI is a tool, but Google Cloud Firestore (a no-SQL data store) is not. At the places you talked to, was everything service-y left to a separate back-end/infra team?

austincheney 5y ago
By tools I don’t mean your OS or IDE. I mean those things so you don’t have to write code beyond a couple of figurations or text content.
- adaml_623 5y ago
  Can you give examples. I'm not clear on what you mean
  - austincheney 5y ago
    * State management in the browser. This is stupid easy. I even wrote about exactly how to do this: https://github.com/prettydiff/wisdom/blob/master/state_management.md https://github.com/prettydiff/wisdom/blob/master/state_manag... * Just about anything to do with the DOM. Its a standard tree model. You learn it and get comfortable with it and suddenly all that browser tooling you cannot live without becomes immediately unnecessary. Hiding from this, making a bunch of excuses, and complaining about how hard life isn't appealing. * The file system is also a tree model. If you have an abstraction layer that normalizes file system access cross OS all you really need is a basic comfort of data structures. * Tools that provide session management are there because planning for real time parallel distribution is challenging. This is yet another one of those that once you go through it a few times you just know how to do it.
  - deleted 5y ago
    [deleted]
  - vincentmarle 5y ago
    I guess he/she doesn’t want to write glue code, but solve actual problems in code.
  - TheHegemon 5y ago
    Looking at the code examples they shared it seems like they are the lone-wolf sort of developer that wants to "solve problems" in code that no one else can read.

TameAntelope 5y ago

Regarding your second point, I think it's good to know what interests you, but there's a lot of quality ideas out there that don't have hard tech components, and if they invent hard tech problems to keep their engineers interested, they're probably not going to last very long. IMHO, the "all JavaScript tech stack, connected together by a cloud provider via tooling" pattern is probably among the faster ways to get an idea from inside someone's head and in front of customers, all of the longer term problems aside. To me personally, the "challenge" comes from being able to do all of that quickly and seamlessly, basically solid execution becomes the fun part. Oh, also I would love to make a bunch of money relatively quickly. :)

handrous 5y ago
IMO the only way to make that stuff engaging is to move "up" a level and be the one picking the tools to solve the problem, interacting with users/clients, that kind of thing. Basically, start your own business or become a product manager at a place where product manager is a fairly expansive role. Otherwise, I agree, it's all of: fucking boring; frustrating; and unrewarding. But, it's also most of the market for developers. :-/
austincheney 5y ago
The business should be inventing the problems, because that is (hopefully) driving the revenue that keeps you employed. Usually the business has all kinds of wonderful ideas of which some are practical and vetted while others are a distraction. If you are thinking in terms of automation, internal training, and service fulfillment you probably aren't properly aligning solutions to expense reduction. The benefit of writing original software is innovation and IP (even if open source and liberally licensed) that can generate additional revenue for the business. If you current approach is entirely dependent upon tools it will be boxed in to a set of configurations and flexibility is lost. From what I have seen on HN the greatest challenge for most early stage startups is finding product-market fit, which means you need to pivot at a moment's notice. That ability to pivot is far more significant than whether you can have a website up in 2 days versus 2 weeks.
- 5y ago