17 ms·

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 w

• sonnyblarney 8y ago
  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'.
  • wolco 8y ago
    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.
  • monsieurbanana 8y ago
    Half is a very, very conservative estimate. Hell, Linux was made 'just cause'.
    • sonnyblarney 8y ago
      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.
      • Delmania 8y ago
        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.
  • ryanwaggoner 8y ago
    Unless they’re your customers, worry not about the nerd-crew. They’re (we’re?) often an anti-signal if anything.
    • sonnyblarney 8y ago
      Or they make up the majority of your company :) I think we're all part of this on some level.
• ryanwaggoner 8y ago
  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...
  • buboard 8y ago
    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.
• agumonkey 8y ago
  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.
• alexashka 8y ago
  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.
• staticassertion 8y ago
  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.
  • wolco 8y ago
    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.
• pier25 8y ago
  It's about priorities and interests. If someone cares about solving a problem, that's what he/she will do.
• MRD85 8y ago
  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.
  • eksemplar 8y ago
    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.
    • streetcat1 8y ago
      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.
      • Swizec 8y ago
        You listen to your experts. Get their opinions. Ask for their logic and their evidence and their conclusions. Then you decide.
        • 8y ago
• crwalker 8y ago
  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.
• rdiddly 8y ago
  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.
  • konschubert 8y ago
    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.
    • closeparen 8y ago
      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.
      • baxtr 8y ago
        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.
        • closeparen 8y ago
• zhoujianfu 8y ago
  My motto is simply, “Hate the process.”
• oftenwrong 8y ago
  http://boringtechnology.club/ http://boringtechnology.club/
• GordonS 8y ago
  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.
  • dwaltrip 8y ago
    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.
    • GordonS 8y ago
      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.
  • akvadrako 8y ago
    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.
    • GordonS 8y ago
      Of course I'm not complaining about a once-in-a-lifetime 4 hours - I mean, I do this all the time!
• jcoffland 8y ago
  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.
  • hnuser355 8y ago
    Yeah, I thought it’s known that many successful products are not really engineering based
    • jcoffland 8y ago
      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.
• Delmania 8y ago
  > 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.
  • nostrademons 8y ago
    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 https://en.wikipedia.org/wiki/Virgin_Atlantic
    • Delmania 8y ago
• tnolet 8y ago
  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.
  • cutler 8y ago
    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.
    • tnolet 8y ago
      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.
    • briandear 8y ago
      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.
• msiyer 8y ago
  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.
  • kbenson 8y ago
    > 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.
    • 8y ago
• Joky 8y ago
  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.
  • Delmania 8y ago
    Which is why you scrap the MVP and rebuild your product with the people who are passionate about the technology and architecture.
• IA21 8y ago
  > 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
• bitwize 8y ago
  > 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.