4 ms·

>I can't pretend to have derived any life lesson that applies to everybody from this Part of what attracted me to software engineering in the first place was a

by m12k 4y ago

>I can't pretend to have derived any life lesson that applies to everybody from this Part of what attracted me to software engineering in the first place was an interest in "how things work", and being able to move between levels of abstraction (e.g. I know how IP, DNS, TCP, HTTP and JSON works, but most of the time I can just treat it as "sending objects"). So it was a bit of a eureka moment for me to realize that running a company is really just expanding the levels of abstraction that you operate with. It doesn't matter how well you code if people can't understand the user interface, so I got an interest in UX and usability. But it doesn't matter how user friendly it is, if it doesn't solve the right problem for people, so I got an interest in product development and customer research. It doesn't matter how good a product is if people never hear about it, so I got an interest in marketing and sales. And it doesn't matter how well I do all of that if I can't pay the bills, so I got an interest in pricing and monetization strategies. Juggling all those needs, and trying to shape the company and all its aspects into a cohesive whole is just as demanding and interesting as doing the same for a software project - it's just expanding the scope of which requirements and concerns you bring into the equation. For me at least, it's also been very rewarding to do the whole thing end-to-end, and it's felt like more of a natural extension of my ever-broadening interests than I would have expected. Bookkeeping can be as annoying as debugging, but in the end I'm really grateful that I understand how each detail works.

chrisweekly 4y ago
Good analogy, and cool story. IME real-world events rarely follow such a linear narrative but I found your company from your profile, and like that its blog -- https://www.hrvey.com/blog https://www.hrvey.com/blog -- shares insights from an "entrepreneurial journey" perspective. Congrats!
rambambram 4y ago
Thanks, this was a nice read. And closing with... > Bookkeeping can be as annoying as debugging, but in the end I'm really grateful that I understand how each detail works. ... hits home for me, haha. Never thought I was going to understand - let alone like - bookkeeping. What maybe helped, was me making my own bookkeeping app, it also forced me to understand the rules.
dataflow 4y ago
> It doesn't matter how well you code if people can't understand the user interface The variation on it I like to emphasize is: it also doesn't matter how "readable" your code is if the user/customer finds it broken, so stop trying to optimize for readability as the primary criterion. {correctness, usability} to the customer > code maintainability > code readability
- mtVessel 4y ago
  I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable. If your code is correct but unreadable or disorganized, it will be hard to extend. If your code is incorrect, but organized and readable, it will be easy to fix. If your code is incorrect and organized, but unreadable, it will be hard to fix and extend, but easy to make it more readable, thus more extensible and fixable. If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. And code is always incorrect.
  - dataflow 4y ago
    > If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. The state you want to reach is "fixed", not merely "fixable". I've seen too many people applying your reasoning staying perpetually stuck in the broken-but-"fixable" state because they prioritize "readability" higher, and I'm saying your users don't care about that. They want a fixed (read: correct) state. > And code is always incorrect. This makes a strawman of my argument.
    - mtVessel 4y ago
      > The state you want to reach is "fixed", not merely "fixable". And my argument is that readable code is the most direct route to that state. > > And code is always incorrect. > This makes a strawman of my argument. It would if it was actually part of my argument, and not a cheeky parting shot. Here's the straightforward version. In my experience, the most productive way to approach code is to assume that at some point a bug will be found, or you will have to extend it. You may disagree, of course, but my views all flow from this assumption.

by m12k 4y ago

chrisweekly 4y ago

Good analogy, and cool story. IME real-world events rarely follow such a linear narrative but I found your company from your profile, and like that its blog -- https://www.hrvey.com/blog https://www.hrvey.com/blog -- shares insights from an "entrepreneurial journey" perspective. Congrats!

rambambram 4y ago

Thanks, this was a nice read. And closing with... > Bookkeeping can be as annoying as debugging, but in the end I'm really grateful that I understand how each detail works. ... hits home for me, haha. Never thought I was going to understand - let alone like - bookkeeping. What maybe helped, was me making my own bookkeeping app, it also forced me to understand the rules.

dataflow 4y ago

> It doesn't matter how well you code if people can't understand the user interface The variation on it I like to emphasize is: it also doesn't matter how "readable" your code is if the user/customer finds it broken, so stop trying to optimize for readability as the primary criterion. {correctness, usability} to the customer > code maintainability > code readability

mtVessel 4y ago
I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable. If your code is correct but unreadable or disorganized, it will be hard to extend. If your code is incorrect, but organized and readable, it will be easy to fix. If your code is incorrect and organized, but unreadable, it will be hard to fix and extend, but easy to make it more readable, thus more extensible and fixable. If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. And code is always incorrect.
- dataflow 4y ago
  > If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. The state you want to reach is "fixed", not merely "fixable". I've seen too many people applying your reasoning staying perpetually stuck in the broken-but-"fixable" state because they prioritize "readability" higher, and I'm saying your users don't care about that. They want a fixed (read: correct) state. > And code is always incorrect. This makes a strawman of my argument.
  - mtVessel 4y ago
    > The state you want to reach is "fixed", not merely "fixable". And my argument is that readable code is the most direct route to that state. > > And code is always incorrect. > This makes a strawman of my argument. It would if it was actually part of my argument, and not a cheeky parting shot. Here's the straightforward version. In my experience, the most productive way to approach code is to assume that at some point a bug will be found, or you will have to extend it. You may disagree, of course, but my views all flow from this assumption.