jconley

I refuse to do those and have fallen victim to it as a founder, so not in my case.

I do the same. But I've done it enough times now that I usually start at the 10k number, just to survive a huge press surge without trouble. Hardware and software is good enough now that this isn't usually much of an overhead.

The paradoxical thing about this for me is that both the most junior and senior engineers fall victim to this line of thinking.

I have done so myself, on both ends of the experience/skill spectrum. As a junior it was because the tech was exciting, and the cool kids were doing it so obviously it was the Right Way to do things. As a senior because I'd been a part of the scramble to scale short-sighted systems in a startup that had found product/market fit and didn't want that pain again.

Turns out you can build the most scalable thing and people still won't flock to your product. And you wasted all that iteration and learning time.

I also enjoy the art of creating something from nothing and improving people's lives. Observing systems and taking a different angle on things than others have done in the past. I've been lucky enough to be able to do this through my work for most of my life, but there have been compromises to live comfortably. Perhaps when my kids are old enough to take care of themselves I'll give up more material things and get back to the pure state of contributing to humanity without thinking about the financial incentives of doing so.

E.g. Would love to bring joy to people by making a game without thoughts of optimizing monetization. Or form a non-profit in various areas. Or spend years on open source software solving big hairy problems.

But for now I'd rather the kids eat well, be able to travel the country for sports, and enjoy a comfortable life.

I think a lot of people touched on it, but when choosing a market for your product as a small team starting out you likely don't choose desktop. Unless your users are primarily on desktop (e.g. pc gaming, software development). These days web and mobile are where the market is at.

It's expensive (time and money) to build apps for multiple platforms even if you use cross platform toolkits like React Native. The tooling just isn't there to make it easy enough to share code between platforms and create compelling products. It generally doesn't make business sense.

I'm working on this problem. Leave a reply and I'll invite you to test when I launch. ;)

If anybody wants to help solve this problem, hit me up. :) Working on it...

Yeah, they're proof that this sort of thing can be valuable.

But they have a very different approach. Proprietary language, components, etc. I wouldn't want to be locked into their ecosystem. That's typical with game engines, but not with web and mobile applications these days. Even Microsoft has gone full open source. I wouldn't use LiveCode as the basis to build a company on.

I'm building the open version. Made for startup teams and indie hackers that want to make world class products on top of the open source tools they would probably use anyway.

Anyone interested in fixing news, and doing it with Web3?

We build an open source and non profit news organization that's a combination of Wikipedia and Genius. The goal is to be a destination that people can trust to provide more than one side of a story and separate opinion from fact. It scrapes news, has an AI that organizes topics, human editors to make sure things are organized properly. It surfaces articles and videos that are meaningful contributors to the topic based on heuristics and editors. We markup biases of authors. Show when articles are making claims that lack evidence. Build a fact checking regime that is open and obvious. We don't do all the news, just pick a few hot topics each day, like Digg.

It has a website, mobile app, probably a podcast.

I imagine the non profit has a sister DAO where good contributors are rewarded with a new token we create. Use NFT's for badges. Various other options.

I'm working on a "Unity for everything else". If you build an IoT product, most anything consumer facing, tools for small business, etc, your customers will expect a multi-platform experience. They want an app on iOS and Android as well as a responsive website. This is currently a pain in the ass to build. You either end up with a very carefully made architecture to share code or build everything a bunch of times or some combination. Huge budget problem. I know, I've had to do it...

Currently looking for people who would want to collaborate on some of the open source pieces that are needed.

Short term I think the right place to start is to build an open source toolkit leveraging NextJS + React Native to create a single project for all platforms.

Long term imagine an IDE (VS Code Extension), hosting, backend ecosystem, marketplace for themes and plugins, a simple opinionated project structure for building things that run on web, iOS, and Android to start. Eventually probably Desktop too. Based all on open source tools to avoid vendor lock-in.

I have a project that will be fueled by scraping. We should chat. :)

I fire engineers like you. You're lucky. :)

Yes, this is generally the issue with open networks. Very, very hard to get complex and disparate client/servers to play nicely with each other. Perhaps with the capital that is being put behind web3 someone will figure this out.

We tried our hardest back in the early 2000's to make this stick. I cofounded a startup building servers, clients, and SDK's. Maybe the world is finally ready for it now. The issue we ran into was customers/consumers just didn't care about federated systems. And various implementations had all sorts of quirks making interoperability between domains and clients difficult, at best. There are just SO MANY THINGS you have to do to make good messenger software that lining up all the pieces with open standards proved impossible in the ~8 years I was working on it. Again, maybe it's better now, but I'm skeptical, probably jaded. :)

Of course if someone wants to cheat at this they can, even with those deterrents. It's a fun cat and mouse game for the cheater, less so for the developer. :) I'd recommend reading Greg Gaffer's articles. He gets into a lot of detail on this in networked multiplayer games. https://gafferongames.com

I feel like this is a lesson that the engineer(s) on every big scale service learns the hard way... :) I wish more libraries did this sort of thing out of the box.

I think the comments so far are spot on. #1 big deal is you need to be networking and finding clients. My comments assume you are USA-based. Many contracts are awarded by someone in an org saying "hey I know a company that can do that."

You should also be charging _at least_ 2x your desired "salary" rate for your own time, more if you can pull it. E.g. if you made $100k/yr that works out to about $50/hr full time. Charge at least $100/hr. You'll need the buffer for taxes, healthcare, finding new clients, liability insurance, un-billable hours (e.g. writing quotes), etc.

If you are good at estimating, try to get fixed bid contracts rather than time and materials. They'll be more flexible and you won't have to be as meticulous with your time tracking. The projects are usually more interesting as well. Hourly contracts are often more like staff augmentation.

A good way to get work if you need to bootstrap can be to subcontract. Research and reach out to other, larger, consulting agencies. They're always looking for subs. Even the bigger ones like TEKSystems and RHI will take on subs (well, at least they used to, I haven't looked recently).

I would plan to work billable hours at most 75% of the time you want to spend working. The rest should be running your business. Marketing, fishing for your next client, networking, handling your business affairs.

Bring on subcontractors if your marketing/sales efforts get you too much work. This is easy profit if you can pull in the work. You should establish a network of trusted people to send subcontract work.

You probably want to use a pass-through LLC as this is a high margin business and you'll want to take profit sharing rather than salary to avoid double taxation and also want the liability protection of LLC. But talk to a good CPA in your area.

We use a forked and heavily modified Saleor at Brava (https://www.brava.com). Our version is over two years old. It brings with it all of the headaches of running your own eCommerce. At the time we chose it because of our requirements. If you want to geek out and implement lots of custom eCommerce stuff then go for it. It's a pretty good platform, but it's custom eCommerce, and eCommerce is complicated. If I just wanted to sell things I'd personally use Shopify or Webflow or such.

Don't take it too seriously. Play the game. It's just sales and marketing and you are the product.

It's probably a good thing as long as they can reuse the training/annotation data. Startups often do full rewrites of underlying technology multiple times as they scale. With the pace of advancement of AI/ML right now I would assume some better algorithms have come along in recent years...

Yeah, given the resources, I'd want to pursue all the possibilities in a promising product/market in parallel. They may have even had working prototypes for some time or even be near launch and they are just feeling out whether the startup would be competitive and/or complementary. Doubt it's anything evil. Just sounds like business minded people at work.

Yes, indemnification clauses are common. Nobody wants to go out of business because of something a customer of theirs did on a platform. Especially when user generated content is in play.

No but I can imagine a senior software engineer that couldn't write FizzBuzz during an interview. I would probably stumble on it myself. I prefer to look at what people have done and not their credentials. I don't hire people that haven't shipped something.

This largely applies to people that have already produced working software in the real world, but...

Companies should trust the people applying based on their resume and ability to talk about what they have done in the past or how they would approach real world problems (organizational, interpersonal, technical). Maybe have them write some small bit of real world code using libraries and frameworks they are familiar with, while they are alone without anyone watching [key|pen]strokes.

Maybe I'm lucky but after 20 years in the industry shipping products to consumers I've never ran into a Software Developer or "Engineer" in the real world that couldn't get things done in a normal working environment in private industry (now in government, don't get me started). Some are slower, some are faster, some can handle bigger problems, but I have no idea how to reliably filter for that in an interview having tried many things.

The "OMG this senior person can't write FizzBuzz on a whiteboard or while videoconferencing and knowing someone is watching your every keystroke so they must be a horrible programmer" approach is just wrong.

I've only ever failed interviews where I had to solve problems or write code with someone watching (virtually or in person). Let me be alone and give me a product to build, though, and it'll get done. Customers will love it and it will be great. See: resume and products in the wild. The Math-oriented abstract tech interview is missing out on all the practitioners that care about the product and can build reliable maintainable systems in a team environment.

These days I'm primarily management, though, so I get to set the hiring guidelines. Yay!

Yes. Also negotiated to get lower rent on the new place. You can probably negotiate with your current landlord if you threaten to leave (of course you have to be willing to move).

Just an anecdote here, but my main spending account and auto loan is with a small local credit union (SFCU). They have been very helpful and proactive in terms of helping people with reduced cash flow. They are deferring payments on auto loans, home loans, and removing minimum payments due on credit cards [1]. Of course, interest accrues. They're not trying to go under too. But I did appreciate the proactiveness. They reached out to members via email and phone as soon as the shelter in place orders started in our area.

It often pays to do business locally with smaller businesses for situations just like this. They're a bit more "human".

[1] https://www.sfcu.org/covid19/

It's deeper than state by state, It's county by county, city by city, store by store. Varying policies everywhere.

In my opinion this is one of those "pick the right tool for the job" problems. If you have a constraint that forces you to have multiple versions in development and maintenance simultaneously then Gitflow works well. This is especially true for things with long QA cycles. If you have a SaaS business and pushed code can go straight to production after automated tests, then don't bother with the management overhead of the versions.

In personal experience... We use Gitflow for our software that ships on our IoT device where we do monthly releases and multiple weeks of QA/reliability testing. Of course, this is coupled with a slow rolling canary release process -- nobody wants customers to be forced return a device due to a bug that can't be fixed over the air.

We also use it on our mobile app and it works well. Again, this is a situation where we have to have multiple versions in development simultaneously. One in "release mode" doing critical bug fixes only as it goes through QA and internal in-home acceptance testing and one for "v-next".

Some 20 years ago we used to do roughly this same process for releasing software on CD's. But, no git back then so no "Gitflow"...

We don't use it for various services and internal tools that can get by without such rigor around versioning. Just simple branch -> PR -> automated test -> merge to master from PR -> automated test -> deploy.

Use the tool/process with the least overhead that manages what you need managed.

I can see it. It's pretty easy to hit that much code when you include your own code for things as trivial as a JSON parser rather than leveraging what the native SDK provides (which was alluded to in the article). It sounds like they had a bit of Not Invented Here syndrome going on and this rewrite addressed a lot of that. It also sounds like they had a bunch of systems (probably different teams even) doing similar tasks like synchronizing state. And they also had their own UI framework. All that stuff adds up to a lot of code. But, all that being said, it still has a ton of features. It's not your father's IRC client sending text around and failing to transfer files through NAT/firewalls.

Brava (https://www.brava.com) | Redwood City, CA | Full-time | On-site or Remote | https://careers.brava.com/ Brava is a leader in home "smart" cooking appliances. Our novel heating and power control technology is married with machine learning, computer vision, and a myriad of web/mobile/platform software systems to help make cooking great food at home easy.

We were acquired last year by a multi-billion dollar public company (Middleby) that owns other premium kitchen brands such as Viking and TurboChef. The whole company is staying together and we have some exciting projects planned.

Our career site isn't up to date but we are hiring various web, mobile, platform, embedded engineering, and Linux engineering roles. We are primarily looking for Mid to Senior level Engineers with at least two years of experience. If you have less than two years of experience please provide references to projects you have completed (boilerplate coding school projects don't qualify).

Extras: 401k, lunch, cash bonuses, stock

Email: jd+jobs@brava.com

I've built a few "chat apps". I wouldn't discount the complexity. They carry with them a wide array of problem spaces. And of course anything at FB scale user counts is going to be a challenge.