583 karma · joined November 5, 2020
I still don't understand the use case limitation, or exactly where this is a potential issue. Why is the data being interrupted? Is this some kind of raw UDP stream use case?
I suggest that video chats are probably the best format for this. Encourage people to work camera on, and to schedule small calls regularly with each other rather than always coordinating on chat/email. Start with some small talk, go into shop talk, and see what naturally falls out at the end just like regular meetings. If you're a lead/manager then set an example to this end and encourage (don't force) others to follow it.
That's bogus. Having the policies be in the same org as the provider just makes sense. You can run a separate security auditing department if you're keen to do that, nothing is stopping you. You can have independent oversight while you don't totally hamstring your organization.
Those auditors aren't also the ones approving expenditures, are they?
People pick suboptimal tech choices all the time. They will continue to do so. I'm ok having competitive advantages over the wider field.
- PWAs have much lower download requirements, whatever your SPA page weight is pretty much the download size. 1-3MB is pretty common.
- PWAs will use lower memory overhead as you don't need a new copy of the browser - it shares with the likely default system browser.
- Launch time can be very snappy even on lower end systems if the base browser is already loaded and you manage offline assets well.
- Don't need to build for Windows, Linux, MacOS. One build serves Web, Windows, MacOs, and Linux users.
Additional cons:
- No guarantee of local storage remaining unmolested by the browser. In practice, it's fine unless a user's disk is filling up then you can get purged.
- Most obvious OS integration limitation is the inability to control the menus on MacOS. You get a generic set that comes with the PWA.
React-native doesn't let you easily reuse your webstack to build it. It's not a web view but a way to create a javascript controlled runtime for a native interface. In my experience it's a rewrite and every effort to share components between react-native and react-web hasn't panned out well.
You can create the simplest of service workers and your done.
If you want better offline ability, you need more TLC in the service worker - which you would need anyway if you want your webview to work offline as well.
The "extra work" takes a few hours. The boons of the PWA over the webview, updates are much much easier to roll out. You don't have a bunch of ancient versions running around. If you don't need access to native APIs this might be worth pushing users to use it.
You can wrap the initiation any way you like. I prefer to make it resemble an app store people are familiar with. Screen shots, user feedback, a description with a "download" button. This communicates the intention pretty well even though it adds an extra step to the process.
I find the biggest hurdle is that people don't realize they can install an "app" so easily and so I try to bridge the knowledge gap.
It might actually be too easy.
Trust is a difficult commodity to build, a lot of company culture issues stem from lack of trust. It's particularly key to the manager/team relationship.
When you have a non-technical manager directly over technical teams it's particularly difficult to build trust. People, emotionally, want to have someone really understand them. Someone who doesn't, at a fundamental level, understand the actual work you're doing is going to be at a disadvantage as the work is crux of the purpose of the interaction.
Not to say that it is impossible, someone with well above average people reading and listening skills can still build that trust and get it. But it's definitely going to be more difficult than someone who really knows the turf.
There's not a lot of lower core count SKUs for these chips either. There's a few GPU tiers and CPUs tiers but not lots of room to go down. Pro has 8/10 CPU cores and 14/16 GPUs. Max is 10 CPU and 24/32 GPU.
There is no 4-7 CPU core segments like AMD does with their chiplets. Intel has much lower tiers for their dies.
The dies are just huge huge huge.
> If they don't have code to share for whatever reason, like it is owned by their previous employer or they are fresh out of school with no code to show, pass on them.
> You have other code to share?
Data would be helpful, but I don't even know how such data would be gathered. Is there a sure-fire method to identify a "Good Engineer" from one who is not?
I interview occasionally, been working a long time. The numbers of devs I know that have such code to share is small, and I would put them all in the work-with-again bucket. I'm not sure if I would adopt this method, but I've seen worse filters :)
Some days I just can't, I'm fried after work, and then I just hang out with the family.
Sure, there are plenty of good engineers who won't have a nice side project to bring up. And you will be auto-passing on them.
The real question is, how many bad engineers are hacking away on a side project they can show off and speak intelligently about?
He is right that his method doesn't scale. He is intentionally picking from a rather small bucket. But that bucket should be pretty high signal-to-noise. That makes his job pretty easy.
When hiring, I often try to filter for "gets stuff done". Side projects definitely help check that box. I also filter for how deep their technical knowledge is for their experience level. I love finding people who are passionate about computers and code, as they always hit above their pay grade, but don't really try to filter for this.
She is well into 4 now, still can't really "read" yet but she can identify surprising individual words. Plays Minecraft as well as her older siblings for the most part. Still a favorite.
The keyboard/chassis eventually wear out. Ports/busses/memory get changed and updated requiring a full refresh anyway. CPUs don't improve that dramatically, the years of doubling performance every 18 months are long gone. 3 years time is likely to result in what, a 30% performance enhancement? If that? That's nice, but not really worth an upgrade cycle. Especially if those enhancements come at a cost of a bigger die/higher price.
I've created 3 products thus far. One is abandoned as failed. One is currently flirting with profitability with about 30 paying customers, there is definitely a positive market signal here, and I'm trying to take it to the next level. The other is an MVP, but it is apparently still missing bits to give it a real go in the market, so it needs more investment. All of my products are B2C.
I've also been working at small businesses for years and have built several products that are not mine. Mostly MVPs style products, but also some more ambitious projects. Mostly I've been the solo dev, but occasionally I run a team. These have also been, largely, marketplace failures. Some have seen success.
I've been really living and working micro-saas for about 3-4 years as both founder and dev. I feel like I've trained my instincts correctly. I WILL make this work, even if I have to build #4, #5, and #6.
I flitted around a bunch of others always looking for quality hosts and topics. I didn't like most of those I found with signal-to-noise too low. There were others, but I can't recall them off the top of my head. I didn't really maintain a list.
For me, it was mostly podcasts on commutes and physical chores. I listened to podcasts about web development, JavaScript, backend, data flows, infrastructure. I built small systems that used this understanding, cementing it in my brain with the pros and cons of approaches where the rubber meets the road. Then I listened to podcasts about small business, particular successful SaaS companies, marketing, sales approaches, management, hiring and all the ingredients that made them successful. Side benefit of this exploratory research is that it makes you very valuable in the market.
Find a need, think of how to serve that need, judge its longevity, quality, and value. Then you put your now sharp tools to work. Idea evaluation is a good skill, and required. You need to be brutally rational about the ideas. Emotional attachment helps drive your motivation to work on it, but it won't magically make customers appear.
Then you try to execute. Good execution is the hardest part, and you give yourself the best shot by head down improvements in your skills. For software, your first goal is to produce something that serves the need and can acquire a few paying customers. The less "other stuff" involved the better, just serve the need. Once you have paying customers leverage their feedback to grow the product and pick the best direction to feel out where the market for it really is. Non-paying feedback is much worse than someone else with skin in the game, paying customers are key.
It's a lot more blood and sweat than the article seems to point out. I like bootstrapping, but it means long evenings and weekends unless you have a sizable nest egg for a runway. Or better if you can afford to work only part-time and can find an accommodating position.
Be ready to fail the first few times and try again. 2-3 significant failures under your belt is pretty normal for a successful SaaS bootstrapper.
If you have the stomach and drive for it. Then you to can reach this definition of success.
There are tons of small underserved markets that would provide nicely for an individual or small team.
PWAs also fit in a niche that is difficult for most organizations to digest. It's fundamentally front end tech, but service workers are non-trivial and also are decidedly outside of the typical front end dev's experience. They resemble backend, but the life cycle is somewhat complex and difficult.
Out of the box frameworks can provide basic service workers, but that doesn't make a PWA really shine.
It's a powerful but unusual tool that's slotted into a strange place. They are rarely used even though they can significantly improve user experience without going full PWA.
Been working in back end and front end for years. The number of front end devs I've met in the wild who understand service workers, their use cases, and how to build one, I can count on one hand.
In other use cases, which there are plenty, different sets of rules dominate. There are plenty of places where SPAs provide a much better user experience than MPA.
I find SPAs simpler to do than MPAs if it fits the use case.
This is the general case on most topics. Accepting the other side's framing is tantamount to "losing the argument" to most people. Often that framing defines the other side as essentially evil and thus not worth listening to or reasoning with. There are precious few places where actual debates where primary arguments are understood and rebutted by mutually respecting parties.