[HN Gopher] Lessons from Bootstrapped Companies Founded by Softw...
___________________________________________________________________
Lessons from Bootstrapped Companies Founded by Software Engineers
Author : BerislavLopac
Score : 45 points
Date : 2023-10-08 11:54 UTC (11 hours ago)
(HTM) web link (newsletter.pragmaticengineer.com)
(TXT) w3m dump (newsletter.pragmaticengineer.com)
| dave333 wrote:
| As co-owner of a mildly profitable bootstrapped software
| enterprise it seems to me the common major weakness is lack of
| sales and marketing expertise to make it go bigger. However for
| many software people this is a feature not a bug.
| quickthrower2 wrote:
| Yes, while more money is welcome, hiring staff beyond say 3
| people is not really what a solo dev wants to do. Ideally hire
| no one!
| Animats wrote:
| Autodesk (ADSK, market cap US$45 billion, founded 1982) is a
| bootstrapped company founded by software engineers with their own
| money. Mostly mainframe UNIVAC systems programmers in their 30s.
| No VC funding; the IPO came well after profitability.
| GravityLab wrote:
| Thanks for sharing, I enjoyed the read. Is there anything like
| this for how companies like these marketed their products to
| generate interest in potential users and onboard new users?
| vore wrote:
| Instead of working fixed hours, I frequently spread out my work
| throughout the day and week. This is a distinct part of Formspree
| culture, that comes from how my cofounder and I prefer to work.
| We encourage our team to choose their own hours, so if you don't
| feel like working a particular afternoon, you can just take it
| off. On the flip side, when you feel the itch to get something
| done on the weekend, it's ok to push code.
|
| What?? Push code on the weekend??? I hope the people at Formspree
| enjoy being inconvenienced at totally random times for when
| someone breaks something on a weekend!
| slavetologic wrote:
| This type of cynicism on hacker news is out of control
| quickthrower2 wrote:
| The culture you want is one of responsibility and ownership. If
| you push to production, you make sure there are some people
| around to help if there is an outage. You make sure there is a
| rollback plan etc.
| is_true wrote:
| I do it all the time. I prefer to enjoy the world while others
| are working. Weekends are also a nice moment to break things,
| most of the people I work with wouldn't notice.
| t1mmen wrote:
| Weird take. Since when does "pushing code" equal "releasing to
| production"?
|
| FWIW, I love this mentality for healthy, work/life-balanced
| teams. It works if you structure around it. I often get the
| itch during the weekend to do a little work, so I go for it,
| because I can balance my days as I see fit. Ride the wave of
| creativity when it arrives, go do something else -- like taking
| a hike, or running errands -- when you can't get shit done.
| wizofaus wrote:
| I assumed the GP was just concerned about somebody pushing
| code to a shared trunk branch that happened to break a build.
| Though as it happens I do know of some shops that literally
| do have a CI/CD pipeline that's so automated such a push
| would result in a production update (of course such a set-up
| wouldn't even allow a push if it did break the build, or
| cause any of the steps in the pipeline to fail). But yes, I'd
| normally interpret "pushing code" as pushing to your own
| feature branch, in which case I'd wonder "is it really so
| unusual for devs to do this out of hours"? I've certainly
| done it on weekends before, but with no expectation that
| anyone would review/merge the changes until normal business
| hours.
| t1mmen wrote:
| It's blatantly obvious that the quote from the article
| isn't talking about pushing to #main and potentially
| breaking production during the weekend. If a team practices
| true CI/CD, they surely have excellent safeguards and
| 1-click (if not automated) rollbacks in place.
|
| I imagine the only people who would think otherwise have
| some pretty dysfunctional repo setups and/or policies.
| deathanatos wrote:
| > _pushing code to a shared trunk branch that happened to
| break a build_
|
| You revert that commit, then. It's broken. A revert
| shouldn't be take as some mark of failure or personal
| offense, it's just that your commit breaks the build, so
| it's getting removed from `main` until such a time as it
| doesn't do that. It happens to us all, from time to time.
| Those reverts almost always carry what at any profession
| organization should be an implied "feel free to bring this
| in a PR again, with fixes".
|
| (And ideally, a bit of introspection as to "why didn't CI
| catch the failure when it was still on a branch?")
| wizofaus wrote:
| "You revert that commit, then. It's broken."
|
| Personally I don't see why it's likely to cause major
| issues to allow people to merge PRs outside of business
| hours either, but depending on your team workflow and
| build pipeline (which may not be fully automated for any
| number of reason) it's not that hard to imagine cases
| where it's preferable to ensure all pushes to trunk occur
| during business hours (e.g. for cost saving reasons maybe
| you don't keep particular services running 24x7 that are
| needed to allow your integration test suite to run
| fully).
| candiddevmike wrote:
| Isn't this the penultimate goal of CI/CD? Release anything,
| anytime, anywhere? I'm envious of a business that trusts their
| process (and their employees) that much.
| quickthrower2 wrote:
| Yes. Also rollback plans/systems and canary releases and
| things like that should be used to minimize the effect of
| mistakes. CI/CD cannot prevent 100% of mistakes.
| dudul wrote:
| Better to break the build on a weekend when nobody is around to
| be inconvenienced.
___________________________________________________________________
(page generated 2023-10-08 23:00 UTC)