* Basic Monitoring, instrumentation, health checks
* Distributed logging, tracing
* Ready to isolate not just code, but whole build+test+package+promote for every service
* Can define upstream/downstream/compile-time/runtime dependencies clearly for each service
* Know how to build, expose and maintain good APIs and contracts
* Ready to honor b/w and f/w compatibility, even if you're the same person consuming this service on the other side
* Good unit testing skills and readiness to do more (as you add more microservices it gets harder to bring everything up, hence more unit/contract/api test driven and lesser e2e driven)
* Aware of [micro] service vs modules vs libraries, distributed monolith, coordinated releases, database-driven integration, etc
* Know infrastructure automation (you'll need more of it)
* Have working CI/CD infrastructure
* Have or ready to invest in development tooling, shared libraries, internal artifact registries, etc
* Have engineering methodologies and process-tools to split down features and develop/track/release them across multiple services (xp, pivotal, scrum, etc)
* A lot more that doesn't come to mind immediately
Thing is - these are all generally good engineering practices.
But with monoliths, you can get away without having to do them. There is the "login to server, clone, run some commands, start a stupid nohup daemon and run ps/top/tail to monitor" way. But with microservices, your average engineering standards have to be really high. Its not enough if you have good developers. You need great engineers.
A lot of people don't know what this Section 174 is about, so here's a brief explainer.
Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit.
Section 174 says you can't do this for software engineers. If you pay a software engineer, that's not "really" an "expense", regardless of the fact that you paid them.
What you've actually done, Congress said, is bought a capital good, like a machine. And for calculating tax owed, you have to depreciate that over several years (5 in this case).
Depreciating means that if you pay an engineer $200k in a year, in tax-world you only had $40k of real expense that year, even though you paid them $200k.
So the effect is that it makes engineers much more expensive, because normally when a company hires an engineer, like they spend on any other expense, they can at least think "well, they will reduce our profit, which reduces our tax obligation," but in this case software engineers are special and aren't deductible in the same way.
In the case of the $200k engineer, you deduct the first $40k in the first year, then you can expense another $40k from that first year in the second year, the third $40k in the third year, and so on through the fifth year. So eventually you get to expense the entire first year of the engineer's pay, but only after five years.
The effect is that companies wind up using their scarce capital to loan the federal government money for five years, and so engineers become a heavy financial burden. If a company hires too many engineers, they will owe the federal government income tax even in years in which they were unprofitable.
These rules, by the way, don't apply to other personnel costs. If you hire an HR person or a corporate executive, you expense them in the year you paid them. It's a special rule for software engineers.
It was passed by Congress during the first Trump administration in order to offset the costs of other corporate tax rate cuts, due to budgeting rules.
YouTube was mostly a library of pirated content when Google bought it for $1.6B.
Spotify began by uploading an employee's pirated MP3s, and is now valued at $92B.
There are plenty of other examples. One of the ways to success is to ignore silly legal matters, build a product people want, and worry about the legality later. It's not just AI companies, the pattern is well established.
[Former member of that world, roommates with one of Ziz's friends for a while, so I feel reasonably qualified to speak on this.]
The problem with rationalists/EA as a group has never been the rationality, but the people practicing it and the cultural norms they endorse as a community.
As relevant here:
1) While following logical threads to their conclusions is a useful exercise, each logical step often involves some degree of rounding or unknown-unknowns. A -> B and B -> C means A -> C in a formal sense, but A -almostcertainly-> B and B -almostcertainly-> C does not mean A -almostcertainly-> C. Rationalists, by tending to overly formalist approaches, tend to lose the thread of the messiness of the real world and follow these lossy implications as though they are lossless. That leads to...
2) Precision errors in utility calculations that are numerically-unstable. Any small chance of harm times infinity equals infinity. This framing shows up a lot in the context of AI risk, but it works in other settings too: infinity times a speck of dust in your eye >>> 1 times murder, so murder is "justified" to prevent a speck of dust in the eye of eternity. When the thing you're trying to create is infinitely good or the thing you're trying to prevent is infinitely bad, anything is justified to bring it about/prevent it respectively.
3) Its leadership - or some of it, anyway - is extremely egotistical and borderline cult-like to begin with. I think even people who like e.g. Eliezer would agree that he is not a humble man by any stretch of the imagination (the guy makes Neil deGrasse Tyson look like a monk). They have, in the past, responded to criticism with statements to the effect of "anyone who would criticize us for any reason is a bad person who is lying to cause us harm". That kind of framing can't help but get culty.
4) The nature of being a "freethinker" is that you're at the mercy of your own neural circuitry. If there is a feedback loop in your brain, you'll get stuck in it, because there's no external "drag" or forcing functions to pull you back to reality. That can lead you to be a genius who sees what others cannot. It can also lead you into schizophrenia really easily. So you've got a culty environment that is particularly susceptible to internally-consistent madness, and finally:
5) It's a bunch of very weird people who have nowhere else they feel at home. I totally get this. I'd never felt like I was in a room with people so like me, and ripping myself away from that world was not easy. (There's some folks down the thread wondering why trans people are overrepresented in this particular group: well, take your standard weird nerd, and then make two-thirds of the world hate your guts more than anything else, you might be pretty vulnerable to whoever will give you the time of day, too.)
TLDR: isolation, very strong in-group defenses, logical "doctrine" that is formally valid and leaks in hard-to-notice ways, apocalyptic utility-scale, and being a very appealing environment for the kind of person who goes super nuts -> pretty much perfect conditions for a cult. Or multiple cults, really. Ziz's group is only one of several.
When mojo was initially released I didn’t think much of it because: 1. It was announced prior to being available, even in closed source form. 2. Emoji filenames meant to me that it wasn’t taking itself too seriously. 3. Many people have tried to make Python fast and failed, and that was my naive take on it, and despite the fact that LLVM allstars were working on it, it seemed like a lofty goal. 4. Closed source programming languages usually suck.
There are some fascinating ideas here, I’m especially excited about what could come from their templated IR. Recommend others give it a watch if they’re confused on why they should pay attention to this project.
This effect of <'a> spreading everywhere is very frequently a novice mistake of putting temporary scope-bound loans (AKA references) in structs that aren't temporary views themselves.
People used to C or C++ perspective tend to reflexively (over)use references to avoid copying, but references in Rust are to avoid owning, and not-copying is handled in different ways.
BTW, apart from edgiest of edge cases, &String is a useless type in Rust, because String already stores data "by reference" and is never implicitly copied. For loans it's generally better to deref to &str.
There's a little more to it: Make sure your manager, and maybe even your manager's manager, likes you. If your manager doesn't like you, change teams. If your manager's manager doesn't like your manager, you should also change teams.
The unfortunate reality of those high growth orgs is precisely that the growth leads to a lot of new managers, and as we all probably know by now, a new manager is a bad manager. Since they have no idea of what they are doing, having the best relationship with them as possible is the only thing that matters.
I've seen the best ICs, and the most effective managers, end up quitting/getting PIPed due to politics. I've seen low performance being rewarded by teams with good bonuses and no deliverable objectives in 2 years, and promotions before ever shipping anything. My evaluation of my performance, and resulting reviews and raises, have minimal correlation: But they absolutely correlate on how much my manager liked me. The more I've focused on this, the better the rewards, the product be damned.
This is extra-true in those rocket ship companies, precisely because things for the company are likely to go well regardless of short term performance: Only major failures, (like what Raylene describes in the article as avoiding being critical) can get you in trouble for actual company impact. In those cases your best bet is to be the firefighter who is also an arsonist, and find ways to sell your solutions to problems you yourself caused... but that involves far too much work.
Note that these may result in you receiving some higher prices by removing some referrer info. If you do see that happening, feel free to remove the offending config if the price difference is significant for you. I usually don't bother for differences of < $10 (price displayed on the search page vs the property page).
> 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.
Eh. If you talk with second-time founders, a really common theme is how inefficient in retrospect the work-all-the-time phase was and how they want to do it differently.
I don't have a lot of data on current <10 person startups, so maybe it's all different now. But the times I was working 80-100 hour weeks were just not time well spent. It was not, "How can I deliver the most in the time I have?" It was "OMG pressure makes me so anxious I'm going to work all the time to avoid thinking about the stakes." It was more drama than effectiveness.
It is also based on gallup data. They determined that employee happiness was not correlated to company success. They did find that the following questions in order were highly correlated to company success.
1. Do I know what is expected of me at work?
2. Do I have the materials and equipment I need to do my work right?
3. At work, do I have the opportunity to do what I do best every day?
4. In the last seven days, have I received recognition or praise for doing good work?
5. Does my supervisor, or someone at work, seem to care about me as a person?
6. Is there someone at work who encourages my development?
7. At work, do my opinions seem to count?
8. Does the mission/purpose of my company make me feel my job is important?
9. Are my co-workers committed to doing quality work?
10. Do I have a best friend at work?
11. In the last six months, has someone at work talked to me about my progress?
12. This last year, have I had opportunities at work to learn and grow?
We are using Django+HTMX for internal applications.
Some random tips:
- Write a "Django context processor" to inspect requests for "Hx-Request" header, and set a "base_template" variable accordingly. This means that any template that {% extends base_template %} will react to being a full page or just a fragment and you don't even have to think about that in your view logic. Great for progressive enhancement.
- You can get reactive JS elements (for example, a d3.js viz that updates when new data comes in) in a few lines of inline JS by using MutationObserver, and "abusing" HTMX by using views that return JSON targeting a <script> element (`json_script` templatetag can also be used here). In summary, you tell your fancy JS element to render or update whenever a particular <script> element is mutated, and all of it is orchestrated by HTMX.
I have been a professional software developer since the late 80s. I was getting a bit jaded and set up my own 1-man software business in 2005. I do all the programming, testing, documentation, support, marketing and sales. The variety of work, the freedom to do what I want and the fact that the financial rewards are directly linked to my work all help to keep me engaged. Interacting directly with my customers also helps. I have stuck with the same basic toolset (Qt and C++) which have grown with me.
If you're interested in profiling, you should check out scalene. It's leaps ahead of every other profiling tool I've used in python and honestly might be the best profiler I've used in any language. It will give you per line results for mem, cpu, and gpu, tell you c time vs python time (numpy calls, etc), and it's faster than most other python profilers.
Some advice (some of it obvious if you've dont it before and not specific for Germany but maybe it's useful):
Have a profile on Linkedin and Xing, upload to sites like freelance.de and maybe to a bunch of agencies. Be ready to send a profile, listing as many projects as possible, i.e. different roles in a company could be separate projects. Make sure all relevant search terms (languages, frameworks, tools) appear for each project even if repetitive. English-only is ok in many places, German-speaking projects can be a little better though.
It's all through intermediaries, which means you can (and should) negotiate rates hard without worrying about burning bridges. No call with a recruiter that didn't go pleasantly ever led to anything so if it feels weird just hang up. Expect to be placed 3-6 months min, 2 years max in a project. Research a little on "Scheinselbständigkeit" but it's not a huge issue these days. If you want 100% remote it should be possible.
Well, you can learn about generative models from MOOCs like the ones taught at UMich, Universitat Tubingen, or New York University (taught by Yann LeCun), and can gain knowledge there.
You can also watch the fast.ai MOOC titled Deep Learning from Scratch to Stable Diffusion [0].
You can also look at open source implementation of text2image models like Dall-E Mini or the works of lucid rain.
I worked on the Dall-E Mini project, and the technical knowhow that you need isn’t closely taught at MOOCs. You need to know, on top of Deep Learning theory, many tricks, gotchas, workarounds, etc.
You could follow the works of Eluther AI, follow Boris Dayma (project leader of Dall-E Mini) and Horace Ho on twitter. And any such people who have significant experience in practical AI and regularly share their tricks. The PyTorch forums is also a good place.
These comments from "How to come up with monetizable side projects ideas" post.
----------------------------------------------
1. Find a popular SaaS product. Like Intercom, Algolia, Segment. Make sure it doesn't have a free plan. This guarantees there's a market for the tool. Check out GetLatka for ideas. https://getlatka.com
2. Build your own take on the product. Find the minimum set of features that make it valuable. 10% of the work for 80% of the value.
3. Sell it at a 50-90% discount. There will be price sensitive customers that want the popular product, but don't want to or can't afford it.
4. Target bottom of funnel marketing channels: Targeted quora questions. Paid/organic search queries. Set up retargeting ads on Facebook. Product hunt launch it. That should get you a steady stream of customers.
I don't think this is a great way to build a million dollar business, but is a very easy way to make a few hundred. Shoot me an email if I can be helpful.
Don't exactly copy another product. It's damn important to reinvent defensible products that either, and hopefully do all of:
a) solve a slightly different problem
b) target different users
c) solve the problem in a 10x better, compelling way
-------------------------------------------------
TIME. Time is the MOST precious commodity. Help users SAVE TIME. Save time finding something of value to the USER. You can't "presume" how much to charge. You have to "TEST" pricing then keep jacking it up until your customers don't pay. How can you pay for something what does not offer value. Stay small. Stay NICHE. Grab a slice from a BIG market. Forget millions. slap-yo-self with fury with delusions of becoming a millionaire, and make a goal of making enough to avoid being trapped in a 9-5 lifer situation. It take a LOT of luck + skill + market segment expertise. Like you have to KNOW the market you are going to be competing in. Assisted living , senior care , retirement calculator is VERY hot now. You'll be at it after your day gig 6pm-2am testing / building / iterating. Good LUCKY. launch a free beta version learn what customers value and how much they will pay ( ask them) THEN when you have enough people crack addict addicted to your service / app start charging. Be merciless. But offer excellent customer service. Always be honest.
------------------------------------------------
While I agree with some of the tactics here (make a twist on similar ideas, contact businesses, buy a business, brush up an existing product you built)
I'm going to suggest an alternative method that has worked for me.
Start with the money.
If you want monetization to be guaranteed you need to prioritize that first.
Take this method and rinse/repeat for you and your skills.
1) How much do you really want to make from this a month, what would make you happy?
Let's say you decide $1k a month would make it worth it after time, expenses and payment processing fees.
2) You then decide how many customers you really want to have to find and how much support email you want to answer.
Usually developers pick prices like $6 and wonder why no-one buys. This low price screams a lack of confidence in the product. That you aren't taking it seriously. That you may not be around in 8 weeks.
Starting without monetization in mind or equally, pricing low is the death of a product because for someone who dislikes marketing you just set yourself a huge marketing mountain to climb.
At $6 each, finding and selling to 150+ customers - when you don't even have one yet is a huge trek to your $1k happy place.
Let's say you feel more confident about finding and serving 10 customers really well. That seems achievable, right?
So with just 10 customers we're looking at a $100 a month product, right?
Whoa, you're thinking you could never build something that's worth that much.
Maybe you're worried it's enterprise level costs now and that's not the type of product you want to build.
Don't worry, a $100 product can be really simple.
Often developers think that a big cost means solving a big problem and that a big problem needs a big solution. Not true at all.
A big problem can be solved with a small elegant solution.
3) Now we know how much we want to make and how many customers we need and how much we are going to sell it for.
We now need to find the problem we are going to solve.
So how big of a problem needs a $100 per month solution?
Not very big at all really.
Let's say a business owners time is super-conservatively worth $50-$100 an hour.
So to add value, we are looking at saving someone between 2-4 hours a month on a task they normally have to do manually. That's not too bad!
Or maybe you want to help them reduce their business costs by $200-$400. Also, very possible. Now we have the value proposition.
We know what kind of problem we are looking for, so value will be clear for the customer.
4) Now we decide _who_ this is going to be for.
Don't pick people the same as you. They have the same skills and can solve the same kinds of problems that you can.
Pick a group of people :-
- That are easily identifiable by what they call themselves on social media (blogger, podcaster, videographer, designer, public speaker etc)
- Make sure they are a group you like interacting with, that you have some experience of working with already in some way (please pick a group you like and care about)
- Make sure they are the decision maker in their own business (don't pick employees of big corps)
- What tech skills have you worked with that overlaps with this customer group?
Let's say you've worked on a few video platforms in the past so you know that space well, so you choose to help YouTubers.
5) What is the issue that we are solving?
Ok, so now we're helping YouTubers to either save 2-4+ hours a month or reduce costs by $200+ - for your $100 MRR product.
This is where we breakdown what it takes to run their business.
What stops them being more profitable?
What tasks do they do everyday?
What can be automated?
What do they hate doing in their business?
If you know this space even a little, you will have answers here.
Maybe video storage is a huge expense.
Perhaps running their community takes up too much time so they can't scale.
Is just publishing a video end to end super time consuming? Look at why.
If you don't know what matters to them, ask. Make a hypothesis and see if it's true.
In just a couple of DM's you might find that they spend a whole day a week on something repetitive. Or are spending money on something that you can optimize. Write a few possibilities down.
6) Make an offer
In just a day or two you can go from no idea, to identifying a significant pain point for a group of people that's easy to reach.
Now you consider a couple of small technical solutions for the problems you've found.
You go back to a couple of your ideal customers and make them a proposition.
Something like - "You said you spent X hours on this particular problem. If I built something to solve that, this week, would that be worth $100 to you?"
If it's a huge pain point they will bite your hand off. If you get weak responses - no worry, you've not built any code yet. You can use the conversation to get to a deal.
They might say it's worth less so you find out what features would be needed to make it worth the $100.
Maybe they suggest a different problem that is more urgent for them.
After a few conversations you should have at least a couple of paying customers and a clear solution.
8) Building
Now you know exactly what you need to build and have customers waiting. There is no excuse but to launch. This will help you focus on the truly essential code.
As you build, reach out to a few more potential customers. (we made sure they were easy to find earlier) Ask them if they have the same problem. Show them what you have.
Go through a few cycles of building and feedback. Make sure people are paying you what you set out in the beginning - or close to it.
Ask your starting customers for referrals. You'll reach your 10 customers with zero marketing spend.
You then have all of the elements needed to scale further if you wish!
Remember that code comes last in this method for a reason. Only build when you have paying customers.
Yes, there are tons of resources but I'll try to offer some simple tips.
1. Sales is a lot like golf. You can make it so complicated as to be impossible or you can simply walk up and hit the ball. I've been leading and building sales orgs for almost 20 years and my advice is to walk up and hit the ball.
2. Sales is about people and it's about problem solving. It is not about solutions or technology or chemicals or lines of code or artichokes. It's about people and it's about solving problems.
3. People buy 4 things and 4 things only. Ever. Those 4 things are time, money, sex, and approval/peace of mind. If you try selling something other than those 4 things you will fail.
4. People buy aspirin always. They buy vitamins only occassionally and at unpredictable times. Sell aspirin.
5. I say in every talk I give: "all things being equal people buy from their friends. So make everything else equal then go make a lot of friends."
6. Being valuable and useful is all you ever need to do to sell things. Help people out. Send interesting posts. Write birthday cards. Record videos sharing your ideas for growing their business. Introduce people who would benefit from knowing each other then get out of the way, expecting nothing in return. Do this consistently and authentically and people will find ways to give you money. I promise.
7. No one cares about your quota, your payroll, your opex, your burn rate, etc. No one. They care about the problem you are solving for them.
There is more than 100 trillion dollars in the global economy just waiting for you to breathe it in. Good luck.
It's rare to see offline support in a web app for a few reasons:
LocalStorage is easy to use but too limited at 50Mb.
WebSQL got deprecated by FireFox because of secuirty issues years ago ( albeit is still somewhat supported in Chrome ).
The FileSystem API looked promising, and then google killed it.
IndexedDb is the only option, it's slow on writes, therefore requiring major hacks like absurd-sql to be performant.
It's also old, written before ES6, needs lots of boilerplate, but it does actually work.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...
Even then however there is a limit of 2GB of persistent storage it can use, which is workable but still:
Some versions of Safari are known to delete IndexedDB after 1 week because of power savings.
Chrome does not allow it unless you either accept notifications from that domain and/or pass a certain lighthouse score (these reasons are anectodal and not well-documented).
So yeah it's a mess, and a bit sad considering it will take years to ratify a better standard for this, but not impossible to do.
Also annoying to know that internally your browser is actually using sqlite under-the-hood anyway.
Web based game engines (i.e. XREngine) are able to get by with IndexedDB i think, and apps like https://github.com/actualbudget/actual created by the author of absurd-sql are good codebases to follow as example.
I would like to offer some tips for those faced with the potential of layoffs that I have compiled. I understand much of these come too late for those already affected, but for those worried about the prospect, these can help to ease the pain if it does happen:
• Check if your company pays out unused PTO, sick days, etc as cash. If they do, do not use any of the applicable type(s) unless you are going to lose it.
• Have a LinkedIn, fill out all the fields, add 500+ random people in your field. Once you have done all this, you get ranked way higher in the algo for recruiters who are searching (you will be granted a visible "All-Star" status, so you will know when you've reached this). After that, go add every recruiter in your field/industry you can find (ideally 500+). Internal recruiters are better than external recruiters / headhunters, but don't neglect the headhunters, especially the "rockstar" ones from more prestigious staffing firms. Finally, add a bunch (500+) of people in your field (who you should now have mutuals with, via the recruiters). Always respond politely to all recruiters even if you're happily employed. Try to be friendly with them, not strictly professional. Build up a rolodex of recruiters. You now have a list of people you can ask for work if you do get laid off. Recruiter-sourced candidates have MUCH better odds of being hired than cold applicants, provided you're not a known name in your industry. If you do this, you'll be able to schedule 40+ interviews in about 3 days, which take place over the following week or two, if you really want to pack them together.
• Don't neglect contract work completely. Many companies have a surprisingly large hiring pipeline of contract -> FTE, provided you do a good job.
• How To Win Friends And Influence People by Dale Carnegie.
• Corporate Confidential by Cynthia Shapiro, if you're in an enterprise / corporate environment.
Someone should build a good, open, web API-based search for OSM data. Not everyone cares about 100% offline capabilities, and improving search would be a massive gain in usability for OsmAnd and other OSM clients.
1. having a network of trusted people you've worked with in the past
2. building some sort of public reputation where people seek you out.
They're not mutually exclusive, but #1 is probably easiest for people already in a job. Go to networking events (covid has muted a lot of this, I know, but it's coming back). Tell people you're looking for consulting work or open to new jobs. Be nice.
Yes, the answer for most people is not fiverr or upwork. I've known a few folks who've done good there, but they're outliers in my network. And even then, the few businesses I've known that have used platforms like that use it as a test ground, and then go direct with someone they click with.
That said, I've never taken a full year salary in 2 weeks. I have taken my own full year salary matching my early earning days from 30 years ago in 2-3 months now.
I hadn't realized it before today, but Jerry Pournelle (a science fiction writer) pioneered here (with two groups, not three, which is an advance in understanding.)
"Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people":
First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration.
Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc.
The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization."
(I have followed this advice, and it has brought me a level of success and comfort I didn’t know I could have, as an admittedly run of the mill developer)
* Basic Monitoring, instrumentation, health checks
* Distributed logging, tracing
* Ready to isolate not just code, but whole build+test+package+promote for every service
* Can define upstream/downstream/compile-time/runtime dependencies clearly for each service
* Know how to build, expose and maintain good APIs and contracts
* Ready to honor b/w and f/w compatibility, even if you're the same person consuming this service on the other side
* Good unit testing skills and readiness to do more (as you add more microservices it gets harder to bring everything up, hence more unit/contract/api test driven and lesser e2e driven)
* Aware of [micro] service vs modules vs libraries, distributed monolith, coordinated releases, database-driven integration, etc
* Know infrastructure automation (you'll need more of it)
* Have working CI/CD infrastructure
* Have or ready to invest in development tooling, shared libraries, internal artifact registries, etc
* Have engineering methodologies and process-tools to split down features and develop/track/release them across multiple services (xp, pivotal, scrum, etc)
* A lot more that doesn't come to mind immediately
Thing is - these are all generally good engineering practices.
But with monoliths, you can get away without having to do them. There is the "login to server, clone, run some commands, start a stupid nohup daemon and run ps/top/tail to monitor" way. But with microservices, your average engineering standards have to be really high. Its not enough if you have good developers. You need great engineers.