HACKER Q&A
📣 barnettx

SWEs turned Founders, what technical skills best transfer to startups?


Student here aspiring to become a tech entrepreneur. While I've shipped side-projects to small groups of customers, I often feel that my technical inexperience means I can't readily translate my vision into a quality product through code. I plan to work at a BigCo/Startup first to better learn the ropes/practices before going it out on my own. The idea is that I stretch my technical capabilities so that when I build my own project, I naturally integrate practices even if I'm developing faster eg. Tests to ensure that my code changes produce the right outcomes.

To SWEs turned Technical Founders, what technical skills/practices/areas from your previous jobs were most transferrable to your startup?

Possible practices/skills I've identified so far include: Clean/Idiomatic Code, Test Driven Development, Design Patterns, CI/CD, Agile, UX Design.

As a caveat, I'm aware that MVPs don't need to be polished products. It's an easy trap to focus on engineering a product instead talking to users. Yet, I do think having the technical confidence is vital for the long-term development of a product.

Post was inspired from reading: https://news.ycombinator.com/item?id=23446627


  👤 Jugurtha Accepted Answer ✓
>I often feel that my technical inexperience means I can't readily translate my vision into a quality product through code.

Value to customer and technical complexity of the solution are independent variables. I can't tell you how many times customers at huge groups with an army of engineers have been delighted and excited with functionality that took an engineer two hours or an afternoon to implement. At some point, the engineers who tagged along were flabbergasted by the lesson: "Of all that we showed, they were impressed with this?"

>Possible practices/skills I've identified so far include: Clean/Idiomatic Code, Test Driven Development, Design Patterns, CI/CD, Agile, UX Design.

None of that matters if you're working on the wrong problem. You'll have beautiful code with 100% coverage that's full of creational/behavioral/structural poetry that go into a tight CI/CD pipeline through many agile sprints and great stylesheets. Only in a coffin. None of this matters if you don't get the "job to be done" right. Maybe as a Kata to beat imaginary or compliant adversaries and stay fit.

I wrote something a couple of days ago here: https://news.ycombinator.com/item?id=25367011


👤 flurly
For me, it's the general problem solving mindset. If you run into a segfault, you don't give up. You open up GDB and start getting your hands dirty.

Similarly, if your users aren't retaining or if your co-founder quits or if your investor is suing you. You don't give up, you find a tool/resource/strategy/mindset and figure it out. Over time your problem solving compounds and you've built an anti fragile company.