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.
Sources: Losing My Virginity (Richard Branson's autobiography) and the Wikipedia page on Virgin Atlantic:
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.
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.
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.
I would call that marketing.
serving the customer happens after they are found, to adapt your solution to the actual problem the customer has.
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.
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.
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++).
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.
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.
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.
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.
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.
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.
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.
When it's 4 days or 4 months, then it becomes an issue.
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.
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.
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.
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.
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.
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.
I bet no one at Facebook can say that
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.
If someone cares about solving a problem, that's what he/she will do.
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.
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'.
I think we're all part of this on some level.
In the backend make it work. Later make it perfect, scalable, etc when new features demand it.
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.
Note that this attitude only applies to people who want to take ownership and deliver a fully functional product. There's tons of great people who are in it for the sheer enjoyment of working with technology, they all will have a great time working on challenging problems at one of the many tech companies. And there's a few people who can both enjoy technical challenges but also switch to dumb and boring crunch mode when it's demanded by the task at hand.