You know I think a lot of the problems is we are looking for magic when it is dull and boring around us. If all else fails, just stay at the surface and say everything is as it seems and nothing is deep or dramatic, and do nothing else but your eisenhower matrix (what’s important and urgent first, four squares on a two axis box). Because when we say nothing is magical we stop looping internally trying to find a touch of divinity when what we need is to interact with the world in a structured way to build momentum to change our environment.
Just listen and help people with your expertise. Be a good advisor. Focus your efforts on finding a good fit for their needs, not selling them something. Talk positively about all the options on the market and the pros / cons. Why you’re a good fit or not for them. Make referrals to the “competition”. It’s not a zero sum game.
The trust you earn by trying to genuinely be of service to the market pays back dividends. Not in an easily quantifiable RoI. But eventually it will.
The other bit of advice is you need to set some boundaries and expectations for working together. This includes closing the sale (we need contract back by X date or we can’t work together) and when executing / serving them (we can’t exceed this limit, we need payment by Y or service will be paused). Hold yourself to being disciplined and not people pleasing. You’ll regret the latter usually. Sometimes the best thing you can do is NOT close the deal.
Don’t undersell yourself. Set a price point where half of your inbound is unable to work with you. Eliminate bad fits early.
As a solo entrepreneur your time is extremely limited. So boundaries and setting a good price point are very important so people don’t waste your time.
And because you’re probably still looking for PmF these trusting relationships turn your potential customers into advisors. Treat your best customers advice as sacrosanct. You’ll find a niche in partnership with them.
When I switched from engineering to management, I spent a long time thinking about software estimates, read about many different approaches, and argued with many other managers (I’ll try to write up my own blog post for the next time the topic comes up on here).
The framing in this blog post is better than some (it at least discusses uncertainty) but I believe it’s still basically the wrong framework.
People (managers) like to assume that estimates are a random variable, and software projects are samples from project space. Estimates can be produced for a project by analogizing it to similar projects. This is not true at all. You cannot reason about software projects by analogy.
Some assertions (that I will explore in said promised blog post):
- Software development is chaotic: arbitrarily small changes in the input (project requirements, who’s implementing it, stakeholders, team, etc) may lead to arbitrarily large changes in time-to-completion (including “this project is now impossible”). In short, any project may explode at any moment prior to completion.
- The risk of a project is particularly sensitive to the engineer implementing it, and depends on that person’s specific knowledge. Have they used these APIs or this database before? Any part of a project that the engineer hasn’t used before represents potentially unbounded technical risk.
- the way to manage this risk is to include buffer in the project timeline, and, critically, to use that buffer not for development tasks that were harder than expected, but for re-planning and re-negotiating the deliverables with stakeholders, to un-explode the project. Agile builds this re-evaluation into the project lifecycle, which is the main (maybe only?) thing is does really right.
You don't understand the power of XML and committee design. XPath could do almost everything. And XSLT in skillful hands could give birth to a blackhole due to information density alone.
The article has some helpful points. But as a programmer-SAAS-founder-who-took-over-ads operation, I have some tips on some insights we gleaned doing paid ads (and getting it to be profitable for us):
1. Most important tip: is your product ready for ads?
- Do not do paid ads too early.
- Do it once you know that your product is compelling to your target audience.
- Ads are likely an expensive way of putting your product in front of an audience.
- No matter how good the ad operation, unless your product can convince a user to stay and explore it further, you've just gifted money to Google/X/Meta whoever.
- If you haven't already, sometimes when you think you want ads, what you more likely and more urgently need is better SEO optimization
2. The quality of your ad is important, but your on-boarding flows are way more important still.
- Most of the time, when we debugged why an ad wasn't showing conversions, rather than anything inherent to the ad, we found that it was the flows the user encountered _AFTER_ landing on the platform that made the performance suffer.
- In some cases, it's quite trivial: eg. one of our ads were performing poorly because the conversion criterion was a user login. And the login button ended up _slightly_ below the first 'fold' or view that a user saw. That tiny scroll we took for granted killed performance.
3. As a founder, learn the basics
- This is not rocket science, no matter how complex an agency/ad expert may make it look.
- There are some basic jargon that will be thrown around ('Target CPA', 'CPC', 'CTR', 'Impression share'); don't be intimidated
- Take the time to dig into the details
- They are not complicated and are worth your time especially as an early stage startup
- Don't assume that your 'Ad expert' or 'Ad agency' has 'got this'.
- At least early on, monitor the vital stats closely on weekly reviews
- Ad agencies especially struggle with understanding nuances of your business. So make sure to help them in early days.
4. Targeting Awareness/Consideration/Conversion
- Here I have to politely disagree with the article
- Focus on conversion keywords exclusively to begin with!
- These will give you low volume traffic, but the quality will likely be much higher
- Conversion keywords are also a great way to lock down the basics of your ad operation before blowing money on broad match 'awareness' keywords
- Most importantly, unless your competition is play dirty and advertising on your branded keywords, don't do it.
- Do NOT advertise on your own branded keywords, at least to begin with.
- Most of the audience that used your brand keywords to get to your site are essentially just repeat users using your ad as the quickest navigation link. Yikes!
5. Plug the leaks, set tight spend limits
- You'll find that while your running ads, you are in a somewhat adversarial dance with the ads platform
- Some caveats (also mentioned in the article)
- Ad reps (mostly) give poor advice, sometimes on borderline bad faith. We quickly learnt to disregard most of what they say. (But be polite, they're trying to make a living and they don't work for you.)
- (Also mentioned in the article) Do not accept any 'auto optimization' options from the ads platform. They mostly don't work.
- Set tight limits on spends for EVERYTHING in the beginning. I cannot emphasize this enough. Start small and slowly and incrementally crank up numbers, whether it be spend limits per ad group, target CPA values, CPC values - whatever. Patience is a big virtue here
- If you're running display ads, there are many more leaks to be plugged: disallow apps if you can (article mentions why), and disallow scammy sites that place ads strategically to get stray clicks.
- For display ads, controlling 'placement' also helps a lot
6. Read up `r/PPC` on Reddit
- Especially the old, well rated posts here.
- They're a gold mine of war stories from other people who got burnt doing PPC, whose mistakes you can avoid.
> By all means, make the case that applications like Tadalist are best run on K8s rather than a set of conventions around bare-metal container/VMs (which is all mrsk is).
Okay sure I'll bite. An application like Tadalist is best run on k8s.
With any application regardless of how it runs, you generally want at least:
- zero-downtime deploys
- health checks
- load balancing
Google's GKE is like $75/mo, and the free tier is one cluster, which is enough. For nodes, pick something reasonable. We're naive so we pick us-west1 and a cheap SKU with 2 vCPUs 8 GB is ~$30/mo after discounts. We're scrappy so we eschew multiple zones (it's not like the nearby colo is any better) so let's grab two of these at most. Now we're in $60/mo. We could go cheaper if we want.
We've click-opsed our way here in about 25 minutes. The cluster is up and ready for action.
I write a Dockerfile, push my container, install k3d locally, write about 200 lines of painstaking YAML that I mostly cribbed off of stack overflow, and slam that through kubectl into my local cluster. Everything is coming up roses, so I kubectl apply to my GKE cluster. My app is now live and I crack open a beer. Today was a good day.
Later, whilst inebriated from celebration, I make some changes to the app and deploy live because I'm a cowboy. Oops, the app fails to start but that's okay, the deployment rolls back. No one notices.
The next day my app hits the front page of HN and falls over. I edit my YAML and change a 2 to a 10 and everything is good again.
Things I did not need to care about:
- permissions (I just used the defaults and granted everything via clickops)
- ssh keys (what's ssh?)
- Linux distributions or VM images (the Goog takes care of everything for me, I sleep better knowing I'll wake up to patched OS)
- passwords
- networking, VIPs, top of rack switches, hosting contracts, Dell, racking and stacking, parking, using my phone
And all without breaking the bank.
---
Okay so I cheated, you weren't looking for a GKE vs on-prem/Colo case. You asked
> make the case that applications like Tadalist are best run on K8s rather than a set of conventions around bare-metal container/VMs
to which I say: that's all kubernetes is.
Did you even read their blog post? virtio? F5? MySQL replication?? How is this a good use of engineering time? How is this cost efficient? On what planet is running your own metal a good use of time or money or any other godforsaken resource. They're not even 40 people for crying out loud. It's not like they're, say, Fly.io and trying to host arbitrary workloads for customers. They're literally serving rails apps.
Want to start small with k8s? Throw k3s or k3d on a budget VPS of your choosing. Be surprised when you can serve production traffic on a $20 Kubernetes cluster.
If you care about Linux distributions, and care about networking, and care about database replication, and care about KVM, and care about aggregating syslogs, and love to react to CVEs and patch things, and if it's a good use of your time, then sure do what 37signals did here. But I'm not sure what that planet is. It's certainly not the one I live on today. 10-15 years ago? Sure. But no longer.
I can't believe just how ridiculous this entire article is. I want to find quotes to cherry pick but the entire thing is lunacy. You can do so so much on a cloud provider before approaching the cost of even a single 48U in a managed space.
At some scale it makes sense, but not their scale. If I never have to deal with iDRAC again it'll be too soon.
You have a horse in this race: apps like Tadalist are best run on something like Fly or knative/Cloud Run or Heroku rest in peace. But a set of conventions around bare-metal containers/VMs? Give me a break.
I don't think you intended it, but I find it disingenuous to separate cloud hosting and kubernetes. The two are connected. The entire premise is that it should be a set of portable conventions. I can run things on my laptop or desktop or raspberry pi or $10/mo budget VPS or GCP or AWS or Azure or Linode or god willing a bunch of bare-metal in a colo. It's fundamentally a powerful abstraction. In isolation it makes little sense, which TFA handedly demonstrates. If you eschew the conventions, it's not like the problems go away. You just have to solve them yourself. This is all just NIH syndrome, clear as day.
Forgive the long winded rant, it's been a long day.
That's the problem with this list: you can read it any way you like, derive whichever conclusions you want. But then you're only looking into a mirror. On its own, the list is just a lot of feel-good bullshit, mixed with stuff that's just wrong. It has very low information content.
> I read this as "certain principles must be upheld at any cost" and I agree with that.
But that's you reading things that aren't in the text. And by itself, it's not a good principle either:
- "certain principles" - which principles exactly? Of them, which ones are related to quality?
- "must be upheld at any cost" - any cost? There's few things in life that truly "must be upheld at any cost", and they're in the scope of morality, not software. Even "thou shalt not kill" is full of practical caveats.
Everything in software engineering is negotiable, all principles have a price. The important parts are all in the details: what exact principles we have, how they trade off against each other, what benefits do they bring, how much do they cost, how much is too much. This list doesn't touch any of it.
You continue:
> E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make.
Yes, now we're starting to see a glimpse of something useful - but it's still a bit too vague to work with. Consider:
- What is "health data" under consideration? For example, someone's smartwatch BPM and GPS log, a result of MRI scan, a list of visits at a clinic, and how old they are - these are all "health data", but fall into different qualitative categories, and merit different level of care in handling.
- What is "dealing with"? Storing? Forwarding? Processing? How? Giving access? To whom? Etc.
- What is "securing that database"? Are we talking access controls against the dev team? The company stakeholders? Securing against script kiddies? Securing against Mossad? In which particular way?
You may feel I'm splitting hairs here, but this is reality: quality is always negotiable, and day-to-day negotiations will happen at this level of granularity. Nobody has infinite budget to respond "yes" to any idea that could be presented as "increasing quality" or "increasing security of medical data".
Developing lists of principles and heuristics is of great value - but this list isn't that. The heuristics you want need to account for the reality we live in (including working around organizational dysfunctions and individual cognitive failures). And they need to be formulated in practical terms, or they'll forever be words on paper. Their only job is to help you answer the question, "is it worth it?", every time you consider two options of different quality.
There's something intoxicating about the idea of building worlds out of systems, feeling like you've captured infinite permutations of some phenomenon in a simple set of rules. This idea of writing worlds into existence with the flick of a wrist is the thing that first got me into computers. In some sense it's the dream that still keeps me going.
My perspective has been sobered quite a bit over the years - these things are rarely as simple as we might imagine they could be - but it remains heady stuff. I can see how it might give the right kind of person delusions of grandeur.
The egoism on display here is pretty offputting, but I feel kinship with the "dreamer" mentality underneath. This guy had a vision, and he was uncompromising in his pursuit of it, and even if the end result wasn't worth much to anyone else, some part of me has to respect that.
I'm reminded of The Room (movie)'s Tommy Wiseau. Another creative who thought he was a genius and poured his blood, sweat, and tears into his life's passion project, and it turned out to be pretty objectively bad. But it was meaningful to him, and there's something to that. There were no ulterior motives; he wanted to put this piece of himself out into the world. There's a purity of spirit. I think what's missing for these individuals is the self-awareness to know that this thing is mostly just for them, and to be okay with that idea and embrace it. That way lies happiness, I think.
I have bad news for you my friend. Everything is a workaround. You do workaround your family, you do workaround your kids and you do workaround your health.
You have seat-belts on your car? Is that a fix or a workaround? Because a fix would be to actually have a car that doesn't crash at all. But would not be economically viable.
You have plastic insulator around your electricity wires to prevent you getting electric shock. Is that a fix or a workaround? Because a fix would be to actually have continuous current at max 12V as power lines. But that's not economically viable.
You have kids going to school and strangers are educating your kids a good portion of their life, molding them sometime against your values. Is that a fix or a workaround? Because a fix would be to have them home-schooled under your eye. But that's not economically viable.
> From your experiences, tell me more! How could this problem be avoided? How does one sniff out such glut?
To a certain extent:
Create a corporate culture where people can get work done without needing to be "protected" from the rest of the company around them
Select against empire-building folks.
Push a culture of reusing and improving existing tools whenever possible.
Recognize and reward people for avoiding and eliminating technical debt, not just for building new things. What you recognize and laud, you will get more of. (There's a balance here: you need both kinds of people.) Hire more collaborators and less "ninjas".
If you have enough budget, empower people to experiment with interesting things without having to hide those folks under a corporate-level justification smokescreen. Understand that some explorations and experimentation will not pay off, and support that anyway, so people don't feel like they have to hide things until they're successful.
Encourage people to report organizational issues and organizational friction, and fix it as early as possible, so that people don't have to create "shadow infrastructure" to get their job done.
I think the brainwashing is somewhat voluntary. When fighting for survival is no longer necessary, most people enter a state of perpetual boredom which, at its extremes, becomes depression and anxiety. An economy of ever-flowing distractions is a great way to pass the time while waiting to die.
In the meantime, we build up these absurd fantasies of how we're going to be important or do great things as a way of justifying our existence, but neither the economy or society can support infinite heroes, so consumerism becomes rampant. People fight for status and recognition with their possessions, not their achievements. After all, most of us value the achievements of others more highly than we value our own, and we place "real" achievement far higher than we can reach and are never satisfied.
Personally, as it relates to work, my job is boring, largely pointless, and will never amount to anything useful, but I try not to let that affect me. I try to always do my best so I am the judge of my "achievements," not others. I spent a week rewriting a terrible contingency plan for IT systems. It's a formality. No one will ever read it, much less put it into practice, but it's well done and I am proud of it nonetheless. Whether or not the hamster wheel moves is, to me, irrelevant. It can move or not move. I pride myself on performing the same regardless.
Thousands, too many to name. If you read lots of code and books, you will be humbled at many brilliant folks that are out there.
Peter Norvig - Checkout his page, and his books PPIA, AIMA
Sandi Metz - Watch her talks
Rich Hickey - Watch his talks
Raymond Hettinger - Watch his live coding sections
Brian Kernighan - read "The Pratice of Programming"
Richard O'Keefe - read "The Craft of Prolog"
John Carmack - The master of constraints and doing more by doing less
Jan Weilemaker - maintainer of SWI-Prolog, read the code
Linux Linus - His stubborness and meaniness has kept Linux together, if he was too passive, the kernel would have been a mess. Design by committe rarely works, someone gotta own it. He owns it.
OpenBSD Theo - Unix systems are better secure because of Theo's stubbornness, lots of branches end up incorporating changes that started from OpenBSD.
TJ Holowaychuk - I think he writes 10,000 lines of code a day
PHP Nikita Popov - The kid is brilliant
Anthony Minessale of Freeswitch
Moxie Marlinspike - the guy that brought us signal
Kyle Kingsbury aka Aphyr, checkout Jepsen, checkout his clojure tutorial.
