Ask HN: 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
5 comments
[ 2.6 ms ] story [ 13.0 ms ] threadValue 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
This. No amount of technical skills can compensate for that.
Perhaps I would rephrase my initial statement as: 'I often feel that my technical inexperience means I can't readily translate my planned solution for the customer's problem into a quality product through code.'
> None of that matters if you're working on the wrong problem.
100% agree with this.
To share a personal example, I was building a system to provide medical workers feedback on whether they wore personal protective equipment correctly. The hospital wanted us to use computer vision/machine learning to automate their checking process. But when we went on-site, we realised that our camera setup, which provided workers a 360 view of themselves so that they didn't need to awkwardly turn to check their behind as they had to do with regular mirrors, was far more valuable than whatever machine learning model we had built. The real problem was actually how could we make it easier for people to wear PPE so that fewer mistakes would be incurred and thus less checking required.
I haven't managed to read all your posts but this one stands out to me: https://news.ycombinator.com/item?id=20356222. The practices you mention are all areas I want to grow in. In that PPE project, as I tried to onboard other developers, things like a lack of documentation and spaghetti non-modular code made it difficult to keep up with the pace of growth we needed. So my hypothesis is that being in an environment (BigCo or other Startup) where practices are being well-used to deliver a product will stretch my capabilities so that I can better execute on my own/in my own team.
In your list of suggestions, how would you prioritise what practices to learn? Or is it about identifying issues in whatever project I'm currently in, having the backlog of potential practices in mind, and then figuring out in real-time how to apply those practices to improve your product/processes
Yes. In https://news.ycombinator.com/item?id=22827841 (product development), I wrote the following:
>The analogy I use is that customers will ask for a robot with IoT and blockchain support that automatically integrates with Amazon API and orders mops, tracks the item, and has AI and image segmentation and recognizes Amazon drone, and receives the mops and automatically loads them. Because AI, blockchain, and IoT. Yes, it's not a sentence.
>Your job is to ask why, figure out they always find water on the floor, and then look up and find there's a leaky pipe, then fix the leak.
>In other words: do not really listen to the "implementation" or the "solution" customers propose. These only fix symptoms and are easily swayed by whatever piece with a clik-bait title prefixed by "This AI robot" someone with 2 minute attention span has written that the customer half read taking their morning coffee, and wanted to bring to the product not to be left behind by the competition.
>What one really looks for is the problem. The problem almost never manifests itself, you have to dig to get it. It's muddy. People could be pissed at you because "What do you not get in an AI IoT robot that orders mops?". This is where having social skills and getting good at interviewing comes in handy.
That is a very common mistake in many projects where you start with a solution (computer vision and machine learning) and try and fit it into a problem.
The sooner people learn to systematically go right to the "job to be done", the better.
We do that systematically through issue templates that try and pry the problem from the person writing the issue. Before that, whenever one of our data scientist colleagues opened an issue on our issue tracker for our ML platform, we'd ask "what are you trying to accomplish?". They'd open an issue going directly to the "solution", but with better issue templates, the message gets across that whatever solution you come up with is "your implementation of a solution to a problem, when we really are looking for the problem itself you are trying to solve".
Same thing with clients. Digging and peeling assumptions and distractions. I remember I was a "coach" on a "start-up" event. I thought they actually had started but they were just pitching ideas. One participant's pitch was "People wash their feet and then go walk on carpets. It's non hygienic. We want to use IoT and computer vision to detect the feet and solve this problem". I asked "So, kind of putting a hand dryer on the floor and putting your feet close enough to trigger it". They went "Huh.. but.. IoT, computer vision".
The hand dryer on the floor works. I use it myself.
That event was a shit show because the people in charge did it in the context of "Smart Cities" and "IoT".
You can witness this in Q&A websites like StackOverflow or similar forums. People ask a question about how to implement a solution. Seasoned contributors will ask the person what they are trying to accomplish. What's the motivation <...
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.