Hacker News Reader

> At this point in my life I've started to believe that whenever you talk to someone who is "passionate about technology X and clean architectures" or "wants to work on challenging technical problems" is ultimately doomed to fail when setting out to create a (for-profit, bootstrapped) business

A flight to the Virgin Isles was delayed overnight, so a strapping young man named Richard Branson chartered a plane to the Isles with money he didn't have. His next move was to create a sign that read "Virgin Airline, $29 a ticket", which he showed to his fellow passengers. They all paid up and all flew to the Virgin Isles that night. Was he motivated by a "passion to help people get to their destination"? Hell no, he had a girl waiting for him and more than likely he wanted to get laid.

That is the only attitude that works for an entrepreneur, the ability to identify problems, find solutions, and get people to pay for them. If you say you have a passion fr a technology or a clean architecture, or that you want to work on challenging problems, you belong in an established company, either as a lead, an architect, or in the R&D. Entrepreneurs understand that technology is but a means to an end, and focus more on solving problems than gold plating something or waxing philosophical about software. They use the tools at hand to solve a problem to the best of their ability. They're not motivated by some grand scheme, their passions are more personal.

That story seems apocryphal. Richard Branson's business empire started with Virgin Records (and in particular, signing Mike Oldfield before Tubular Bells became a huge hit), and the name came from him sitting around stoned at a party/orgy with a bunch of friends and saying, "Well, we're all virgins in business, so let's just call it Virgin Records." He's not a cofounder of Virgin Atlantic - the cofounders were Randolph Fields and Alan Hellary, and Randolph met RB at a party in which RB agreed to put up all the money in exchange for a large equity stake. He was already wealthy from the success of Virgin Records, which had been in business for a decade.

Sources: Losing My Virginity (Richard Branson's autobiography) and the Wikipedia page on Virgin Atlantic:

https://en.wikipedia.org/wiki/Virgin_Atlantic

It's not.

https://www.businessinsider.com/richard-branson-entrepreneur...

https://jamesclear.com/successful-people-start-before-they-f...

https://en.wikipedia.org/wiki/Richard_Branson#1981%E2%80%931...

That story is not how Virgin Atlantic was formed, it's more about his first experience with making money in the airline industry, and would later lead to his decision to agree to a partership.

Beyond that, it's more a look into the mindset someone requires to be a successful entrepreneur. It's not about the technology, the architecture, or the language. It's about identifying a problem, and getting people to pay you for a solution. The technology is tertiary.

Branson tells the chartered plane story in Losing My Virginity, so I don’t see how you could consider it apocryphal if you’ve read it.

You're really just talking about the differences in skill sets and interests between people who, in a bigger organization, would be sorted into the engineering team and the executive team. The "passionate about technology" people will end up in engineering. To the executive team, finding and serving the customer is the focus, while technologies (and engineers for that matter) are very much a cost that has to be justified.

But yeah they're different skill sets. The only time it's a problem is when they both have to reside in the same person, for example the solo app developer. You're trying to serve as both the engineering staff and the executive/management team, plus wearing several other hats as well.

The problem is that an engineering team full of developers that only care about processes, clean code and learning new stuff is mis-aligned with the goals of the organisation. It will take a constant uphill battle to take them to ship anything, something that generally isn't worth it I believe.

Of course technical debt needs to be paid and clean code is the essential foundation of every productive company. But as a developer, you need a desire to SHIP as well.

A process worth caring about leads to shipped software, and production is the wisest teacher and the most thorough QA. Shipping is important, but then you have to keep resources committed to quality improvement, not move on to the next shiny new thing.

That’s one of the biggest misconception I’ve experienced with developers. No one cares about whether you ship or not, unless it brings values. Shipping just for the sake of shipping is a fundamental misunderstanding of how a business works.

Well, sure, but whether the software has business value is the concern of the PM. Developers are usually haggling over the balance between speed of delivery and quality, for a fixed set of requirements.

> To the executive team, finding and serving the customer is the focus

I would call that marketing.

marketing is to find a customer with a problem for the solution that you already developed.

serving the customer happens after they are found, to adapt your solution to the actual problem the customer has.

I agree.

I have known people who would not move to the next chapter in a book unless they understood the one they are reading in its entirety. I have pointed out the inherent impossibility of such an endeavor. They do not listen. I think this obsession with tech stack or architecture is related to this.

I am extremely passionate about a lot of subjects. However, I am not passionate about "technology X or Y". Technologies and programming languages are just tools for me. I like some more than the others, but they are just tools. It is like saying that I have a great novel in my mind, but I cannot write it down unless I have the "Pen A" or "typewriter X". Also, I will not write the next page down unless I get the current page 100% right. Never gonna happen.

Heck, when I began learning C# a few years ago and people would question me "where do structs in C# live? on the stack or in the heap?" I would get mightily pissed off. How was I supposed to know the internals of a closed-source (erstwhile?) language\framework? What if they change the internals tomorrow? Would this "knowledge" be of any use?

I have ideas. I need tools. I need results. The universe is all about entropy. The internals are constantly changing. However, as a giant mechanism it is always working, always producing results.

> What if they change the internals tomorrow? Would this "knowledge" be of any use?

Sometimes. I think the best response in theme of the thread so far is "When it starts to matter, I'll spend the time looking into it. Until then, I try to know just enough to clue me into whether it might matter."

As a concrete example, I know why stack and heap matter for performance, and I know that maximizing computation in a hot loop in something like assembly requires a fair bit of knowledge of the architecture and what instructions utilize what resources in a CPU you you can plan out usage optimally, but beyond reading some interesting articles that have popped up here, that's all I've bothered to internalize. I haven't done almost anything in C or C++ since college well over a decade ago, and all my day-to-day work is done in Perl. At the point I'm in need of a customized very optimized solution for a computationally heavy workload, I have promising avenues of inquiry to start with. The way I see it, that the optimal strategy for my current goals, and it's been the optimal strategy for quite a while.

>> "When it starts to matter, I'll spend the time looking into it. Until then, I try to know just enough to clue me into whether it might matter."

Exactly.

Stack and heap are not important in the C# example I gave. What matters is whether the data structure is a "reference type" or a "value type". This impacts the way we pass arguments to functions, scope of a variable and related side-effects etc. However, where these types reside has very little meaning since the memory allocation and cleanup etc. are not in developers control at all (unlike C, C++).

You're right, but it's kind of sad. We value flashy POCs, not robust, safe software. And look at the state of the world right now - garbage software everywhere.

It doesn't have to be flashy but it has to make money and can scale. The focus should be how can I make money, then build the product around that.

Being able to build the full product in a day allows you to pivot.

A side project doesn't have to be a business and probably shouldn't to start with. Why not build a game or app get as many people playing. Once it reaches a level you can try to make it a business afterwords.

This is a great summary of the zeitgeist of today's Silicon Valley and also totally wrong. You can do great engineering and build a successful company from it with out settling for low hanging fruit but, it requires a longer than average attention span, not needing to make your investors happy by the end of the quarter and a marketing plan.

Yeah, I thought it’s known that many successful products are not really engineering based

Yeah, but they aren't tech companies. Lot's of other roles are needed for a successful company, legal, marketing, personnel, management, etc. but the value of a tech company is created by engineering.

I wish I could upvote this 100x. If I had a nickel for every successful founder who hacked their first version together in PHP instead of trying the latest framework, or worse, starting with a technology they’re in love with and then looking for a business problem to solve with it...

plus the "hacked in php " version is far more likely to work 20 years later because php is boring and people don't care enough about it to mess it up every week.

I really love difficult technical problems but luckily I'm still a CS student and have time for that. One thing I've been realising more and more is that if I want to make a good living working for myself the real problem is selling products to people who don't care at all about the technical side of it. They want a product they enjoy using that solves a problem of theirs, that's it.

It depends on what you want to do. There is a lot of room for technical experts who want to build products for other people.

I’m a manager now, and have been for years, but leaving product building behind was one of the hardest things I ever did. I did it because I wanted to make decisions more than I wanted to build things, but that’s not for everyone and it’s not as glamorous as it sounds. I could just never help myself from getting involved in every decision, and then it’s frustrating not to have any real weight, and you won’t as “just an expert”, even when you’re right. A lot of people prefer to just build stuff, and in CS and engineering especially, those people aren’t easy to come by or easily replaceable, and thus they are valuable.

My free time is still spent doing silly CS stuff though, I recently discovered edX.org, and I’ve been fooling around with cryptography.

So you’ll certainly have time for that, even when you get older. The only time I didn’t have time was when my kids were 0-6.

So how can you make a technological decision if you do not have hands-on experience with the technology (at least a year of deep immersion)? It sounds like the most important decision (whats to build) are at the hand of the least knowledgeable person.

You listen to your experts. Get their opinions. Ask for their logic and their evidence and their conclusions. Then you decide.

Right. So why do you decide and not the expert decide? So the expert can be smart enough to come with a solution but cannot "decide".

My point here is that once you become the manager, you should constrain yourself to the functionality (input/output spec), but you cannot decide on technical issues if you are not keeping up with the technology.

Because the technical truth is only part of the equation.

The right decision almost always boils down to a combination of experts, finances, end users, over all strategy, corporate culture and realism.

The variables variate in importance, but the one thing you can be consistently sure of, is that experts over value theirs.

On top of that, decision making is only a small part of management. The majority of it is spend on politics, motivation and issues/conflict resolution.

Because decisions are rarely down to just one field of expertise, and technical experts are often some of the least knowledgeable about fields that aren’t theirs.

Like if you build a new application for handling internal e-commerce. The programmer will know how to build it, the service designer will know how to create the ux, the lean consultant will know how to build the best work-flow, the financial expert will know what functionality is required, the project manager will know how to get things build in the right order and how to manage benefits, the hr-consultant and the lean consultant and the service designer will know how to get it implemented, the data scientists will know what kind of data model their like to do BI. And so on.

The right decision is to listen to all those inputs, and implement them in a way that’s both realistic, possible within the budget and making sure the final product actually fits in within the organisation.

That doesn’t mean you won’t delegate. I don’t really care if it’s build with graphql or not, as long as building it with graphql doesn’t increase production time by an unreasonable amount of time compared to other options and graphql is part of what our company in general uses.

Because the best flashy new tech is useless if only 1 out of your 100 programmers know it.

Funnily enough, I've been working on my transition to a CS career while my kids are in that age bracket. I work full time in the military and study CS, as a single parent, while my kids are 5 and 3 (I started when they were 3 and 1). I'm a tired man.

My end goal is to work for myself, I want to own a company that builds products. This can be either products that we own or building for others. I love building things but I'm now trying to learn about the art of selling and finding a customer base.

This seems really observant. If the true goal is "building beautiful tech" then shipping an actual product usually takes one (far) away from that goal. Those who appear to self-sabotage by pushing back launch dates may simply be revealing their real goals. I think it's critical to honestly evaluate motives before starting a project to avoid burnout.

http://boringtechnology.club/

This is something I really wrestle with. I intrinsically care about clean architecture and clean code so much that I spend far too much time procrastinating and gold-plating. I realise I'm "doing it again" every so often, but invariably tell my self "yeah, yeah, but it won't take much longer". 4 hours later, I'm still at it :/

I don't know if it's my enterprise upbringing (been working for a megacorp for ~20 years), my love of tech, or my language of choice (C#, which I love, BTW), but sometimes I wish I could just ship a working product.

You could do a very small side project where the requirements are:

1) simple, polished, functional UI

2) quick and dirty code

If the code is nice, then the requirements aren't met! You might even write this in large letters on a piece of paper or whiteboard next to your desk at home, keeping it visible while you work on it.

Environmental clues like that can sometimes be helpful for me. I view it as an attempt to collaborate with "future me". Sometimes the collaboration is a failure, other time it is a great success. I think one can get better at this as well.

Back on topic, one phrase I really like "Make it work, then make it nice". The definitions of "working" and "nice", of course, will depend on the context. But I find it to be a helpful maxim.

I have a regular reminder in my phone that just says "Ship, ship, ship!", but yeah, maybe I could do with something more permanently visible.

You're complaining about 4 hours? If you can spend 4 hours to make your code easier to understand, that's very likely to save someone 4 hours down the road.

When it's 4 days or 4 months, then it becomes an issue.

Of course I'm not complaining about a once-in-a-lifetime 4 hours - I mean, I do this all the time!

I see. Well I used to have a tendency to start refactoring something, then see it’ll be easier if I refactor another part and so on.

I would dig myself into a well so deep it might take a month to crawl out of before my code is useable again, but it would be a huge waste to stop.

If you’ve only invested 4 hours it doesn’t seem that bad.

Set dates and work backwards. Even better, get people to pay you and the then a date. Desiring to meet the expectations of paying customers can motivate you to cut the fat.

I'd go as far as saying clean code as an anti thesis to starting a business. Clean code is a huge battle in itself but not the battle you need to win when starting a business. Clean UI though is a different story.

Thank $$d someone someone else thinks this. I would add that TDD is a joke if you're serious about getting a product out as quickly as you can. TDD stifles that essential, fast-paced creative process like nothing else. Tests are fine. It's just TDD I have a problem with. If you have plenty of VC money to burn sure, burn it on TDD but if you're on a tight budget it will kill your ability to ship.

The problem often is many people take statements like mine “clean code is anti starting a business” much to literal. Your code needs to be somewhat clean, just clean enough to make it to the next round. You could do TDD on that one part that is super duper critical, just not on the part that is doing basic API stuff or something run of the mill. I guess assessing nuance is hard.

I couldn’t disagree more. TDD makes it possible to ship a more reliable product without superfluous code. TDD also makes it possible to move more quickly without breaking things. That “fast-paced creative process” turns into an albatross when your new stuff is breaking the old. The VC types are the ones that can actually forgo TDD because you can simply hire a lot of QA. When you are trying to ship “fast,” TDD reduces QA time and also ensures that your developers aren’t breaking each other’s work. I have hired by plenty of test-optional companies and they struggle with adding features or wonder why their application slows to a crawl with even a few hundred users — yet without tests fixing those problems results in new development grinding to a halt.

In XP parlance, a spike is specifically to allow for rapid development of a feature idea, but your entire development process ought not be a spike or it will bite you in the ass much sooner than you think and at a point where you can least afford it: when you have some mild, but not strong traction and churning users from buggy code is a real problem.

Unless you have some viral-type product (like Facebook,) move fast and break things is a terrible strategy if you care about creating a sustainable business.

Make it work, make it scale, make it elegant is smart advice, but part of “make it work” means that it doesn’t break. I would argue that pure TDD isn’t necessary, but I would adamantly suggest that shipping code without tests is far more risky than just hoping you catch issues when clicking through the application. Whether you write tests first or code first, that isn’t the issue — as long as you have tests before you ship. If you fail enough times with building a business, that’s the first thing you’ll learn.

Total BS. That is the bill of goods sold by TDD. In TDD the tests become as critical as the code and they are an anchor that weighs you down and slows down time to delivery. It isn't that tests are bad. Build the code, write tests to support anything critical that is a risk, but for the sake of all that is good throw out writing tests first or any notion of 100% test coverage. It's a huge time suck that does not balance out in the end.

I hate on TDD as much as anyone, but there really are occasions for its use. Specifically when the results of working code can't be determined by the person running it. The simplest example I can think of is something like a math library -- if I have code that computes the cosecant of x, I don't really know if it's working or not.

On the other hand, I really don't need controller tests for my 1.0 version -- if they aren't working, it's immediately obvious. Circle back later and throw a test on it to nail it in place if need be, but TDD is absolutely not needed when development is obvious.

If you've failed multiple times trying to start a business, I'll guarantee is not because of my doing TDF but because of poor product market fit. You'd be surprised how much crap a user will put up with of your products fit their needs.

I want to ship complete code ASAP.

However, I would allow for refactoring that deletes large swaths of code. This keeps the codebase lean and maintenance low — so that you can keep up the fast pace.

The problem to me is that this is used too often as an excuse by sloppy developers to not care about the quality of the software. It is too easy to overlook the impact 6 months down the line of the lack of design/readability of some piece of software.

I have seen this too often. Technical debt is OK when it is managed. I.e. taking shortcut when we need to ship a product or reach an MVP in 3 months is fine, but having a sustainable software will require to pay back some of this at some point, or velocity/quality will suffer on the long term.

Which is why you scrap the MVP and rebuild your product with the people who are passionate about the technology and architecture.

> so they, and we, can get off that damn computer screen and enjoy the fruits of our labor

I bet no one at Facebook can say that

> If you're saying "I'm passionate about delivering great products to users" or even "I'm passionate about making money" (I respect that) then technology becomes the tool you unfortunately have to wield to arrive at that goal.

I've had crooters say to me things like "I don't get the feeling that you're really passionate about these technologies". At which point I begin wondering what universe the crooter is from.

80% agreed. It's a good thing not only in terms of material ROI but also intellectual and emotional. 'Smallest solution' is always nice to do.

It's about priorities and interests.

If someone cares about solving a problem, that's what he/she will do.

What they're really saying is - "I don't understand the full tech stack, I'm interested in gaining that knowledge"

What you're saying is - once someone understands the full stack, they're much more likely to create something good, because they're spending their efforts creating a product, instead of fighting the technology and learning how to wield it.

Indeed, people who understand the tools have a better shot than those who don't.

My motto is simply, “Hate the process.”

Passionate about outcomes, not the means.

The only thing is by not giving a smack about the tech is that you risk looking like one of those 'impostors' by the nerd-crew who think everything is about the tech.

Also ... there are intangible benefits from our hard-core nerd outs. Let's be real: 1/2 of the tech we used may not have been invented if it were not for some dude doing it 'just cause'.

It depends on your customer. If you happen to sell api services make sure the public face is at an acceptable level.

In the backend make it work. Later make it perfect, scalable, etc when new features demand it.

Half is a very, very conservative estimate. Hell, Linux was made 'just cause'.

Though I do agree to a great extent - I also think Linux was made (iterated, improved upon, invested in by so many) with pragmatism and 'customer' (i.e. users) satisfaction in mind - it just happens to be free. Meaning, a great deal of the same 'outcome orientation' without being so overtly commercial.

The reason that Linux took off was because it gave the FSF a working operating system kernel they could use to build their UNIX replacement. It was a rare case where someone's personal project matched perfectly with the needs of a group they were associated with. People wanted a replacement OS and Linus delivered just enough people could make that happen.

Unless they’re your customers, worry not about the nerd-crew. They’re (we’re?) often an anti-signal if anything.

Or they make up the majority of your company :)

I think we're all part of this on some level.