Sorry, bud, I worked with a couple of guys like you before - very bright, smart, self-confident, young, yet started coding before they started drinking, but with not a lot of mileage in the industry - and the problem was that this style of work is not compatible with other people. It's great for prototyping. It's great when you work alone, but it's a nightmare in a true team environment and the resulting code is nothing but a headache in a long term.
I'm sure you can ship, but that's hardly an achievement. Everyone one can, but shipped out shit in a working condition is akin to all that Made in China crap from Walmart. Nothing to be proud of to put it mildly.
> So next time you’re working on a project, give some thought to what’s most important: speed or elegance.
It's "Fast, cheap, good - pick two" and "You get what you paid for".
Any tool can crap out code that serves a business need. That's a "product", fine. But it takes someone with a bit finer sense of competence to produce code that can work over a longer term and doesn't drag down the business in years to come.
Yes. The term "quick and dirty" and "bang something out real quick" make me want to throw up in my hat. It's not like it's not necessary to lower standards a bit sometimes, but because people who use that phrase a lot tend to, in my experience, use it as an excuse for churning out a lot of garbage.
I generally agree with you, but it really depends on the context. You can never abstract the development side from the business needs, and those trump everything.
In a fast business with a very small team and a very short runway you often have to sacrifice quality in exchange for putting something out there. If something doesn't come out of the oven, there's no "long term". At that point, the choice makes itself. That's probably why a lot of people will, likely rightfully, claim that startups don't need to be highly technical unless it's where their competitive advantage will come from (and in the words of Mark Suster, 90% of startups do NOT fail because their tech wasn't good enough).
On the other hand, in long-term projects that have enough budget to survive for a while, you can shift priorities and focus on quality as appropriate.
The release process is also really important here. In web/saas you can fix things very fast behind the scenes without the customer being aware of it (Etsy claim to make what.. somewher around 100 checkins into production a day?). In mobile / boxed you have to be a lot more careful. Nobody wants to wait 2 weeks for Apple to approve your patch when a major scenario is broken in your app.
Of course, if you can have both wonderfully clean and extensible code and get that done exactly as fast as poorly written code, that's the preference.
This post just completely rubbed me the wrong way. It came off as an arrogant boast by an immature developer framed as an admission of shortcomings. But it was only an admission of shortcomings in title. He spends the majority of the post tooting his own horn about how people want to hire him, and how he's actually a good programmer because he ships code, and because he's worked at startups. He keeps posing these meatball questions and then answers them in a way that makes him look as good as possible but doesn't really provide an answer to the question "what makes a good programmer" (probably because it's a loaded question and depends on context). He's just setting himself up to say "a good programmer is like me because in this example I did a certain thing that made sense at the time." He also mentions that he's a college junior at least three times on that page and makes sure that we all know that all this insight and maturity is coming from someone still in college who's not even studying computer science!
>Sorry, bud, I worked with a couple of guys like you before - very bright, smart, self-confident, young, yet started coding before they started drinking, but with not a lot of mileage in the industry - and the problem was that this style of work is not compatible with other people.
Me too. And it's not just the code they write that's a headache - they're usually a pain in the ass to work with because they always know way more than everyone about everything. They know more about algorithms, they know more about software engineering, they know more about software design, they know more about human nature and the industry. They even know more about things they know nothing about. Meh.
I am young in the Industry and I already see examples of such people. They go through a recursive cycle of "visible productivity" in terms of fancy features which break three months later. Then, they are on a "fire fight" trying to fix this "broken feature". The worst thing you could do is try to look at their code and attempt to reuse components for anything you want. I however don't completely blame such people, I think it is the nature of the startup world we are living in where the idea is to ship as fast as possible and technical debt be damned.
Sorry, bud, I worked with a couple of guys like you before - very bright, smart, self-confident, young, yet started coding before they started drinking, but with not a lot of mileage in the industry - and the problem was that this style of work is not compatible with other people. It's great for prototyping. It's great when you work alone, but it's a nightmare in a true team environment and the resulting code is nothing but a headache in a long term.
I'm sure you can ship, but that's hardly an achievement. Everyone one can, but shipped out shit in a working condition is akin to all that Made in China crap from Walmart. Nothing to be proud of to put it mildly.
> So next time you’re working on a project, give some thought to what’s most important: speed or elegance.
It's "Fast, cheap, good - pick two" and "You get what you paid for".