To me, since the DB is there to serve the app (which is there to serve the user), the lookup/enum decision mostly depends on whether the list is defined before build time (> enum) or after (> lookup).
US states are probably a solid "before", so you get the added value of easily materializing a validator in the app code.
Children IDs sound a bit more dynamic.
I've been working on this for the couple of last months. I found this project to have multiple tech angles (pcb, electronics, C-level ESP, Python, webui / Javascript, machine vision), an figured it might be an interesting read.
I don't think anyone did anything similar to this, and maybe people would like the idea and make their own e-ink poster
Is Django's ORM even supported outside Django sites?
I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.
There's nothing forcing you to use the HTTP stack. It's very common for Django applications to also have a Celery worker for async tasks. The Celery worker is a separate process (possible on a separate host) which use the ORM without any of the HTTP portions.
You can also write custom standalone scripts which use the ORM. Django has a concept of "management scripts" which are also kinda like that (but with a bit more scaffolding).
We've been running Django's orm under litestar without any issues for maybe 2 years now. We just run django's setup with a minimal settings config as a part of the app startup
While interviewing post-FB to other companies as an SRE-type-engineer, it seemed to me that outside of FANN it's not common to give engineers a very wide scope. One company asked me whether I'd like to join the monitoring team or the container team, to which I replied "why can't I work in whatever team needs me the most, and switch whenever needed?". They didn't like that.
After trying and failing to find a part-time position I like (can expand on it if interesting), I ended up joining as an architect to a "fixer-upper" company, where I have a lot of things I can improve and wide scope. The money isn't up to par with FB, but I feel I'm doing meaningful work and making the world better, which was missing from the last couple of months at FB.
If you appreciate wearing a lot of hats and roving around to create real value, it might be worthwhile to look into going independant!
I'm ex faang and have managed to carve out a comfortable independant consultancy where I can kind of join needful organizations as a roving 'fix-it-up' engineer at large, answering to the directors who (hopefully) only care about things working better.
It's gratifying to swoop in and fix real problems for teams, and also get a view on cross team efficiency opportunities that most siloed org-structures don't have good visibility or agency to tackle.
I tried doing that, but couldn't land a starting gig with reasonable pay. To my impression, the market is flooded with cheap-to-hire people and I couldn't make my quality stand out enough to get interesting clients. If you have any tips I'd be happy to read them either here or at cv AT backslasher.net
EDIT saw your reply. That's a great experience! I tried that but the timing / friends / luck didn't pan out there. I'm happy you got it working though :)
I started down this path before deciding it wasn’t for me. The path I found was to get hired on as a sub consultant to a software consulting firm which gave me the time and legal freedom to pursue other work on the side
Replying here, but also to the other response:
I don't really have a formula (and if I did, I best be trying to sell it!) but for my case, it came down to letting friends and colleagues know that I'm open for work, and settling in to work on an interruptable bootstrapping project. The bootstrapped work has never come to fruition though it has been useful and may still become viable IP. But by word of mouth I came into working for a MedTech organization that needed a sizeable data normalization and analysis pipeline built. This could have been full time W2 work, but by that point (and after more than one burn-out) I had made up my mind that I was more of an 'outside cat' engineer that comes and goes as they please, and I asserted that I would work on a 1099 basis. This may or may not have been wise, but it did set the groundwork for being independent. It also introduces a subtle but impactful change in one's relationship to the organization that they are working for.
Case in point, about a year into the MedTech work, I was contacted by someone I knew at a large local cyber-charter school who was looking to build out a SWE team (as leverage with the other contractors they were working with). If I were a full time employee, the answer would have been 'Sorry, I'm busy'. But, as a 1099 worker with no set hours, I was happy to help them do interviewing to build out a core team. This lead to a long term advisory relationship with them, firefighting when things exploded, and also building a ton of automation and data governance back office utilities.
There have been some other tasks too, but if I had to boil it down to a few pithy points it would be to: play HARD to your strengths and be flexible.. But also don't be afraid to turn down work if you don't think you can hit it out of the park. Let everyone know that you're open for business too. A lot of organizations would be happy to have a problem solved without having the overhead of onboarding an employee.
This is predicated on you cultivating the level of experience and autonomy needed to get things done without oversight, or, in-fact, providing oversight of others trying to do 'the thing'.
My current challenge is in trying to move away from hourly billing and on to project-scoped contracts. Eventually I would like to build productized services and IP that make money while I'm asleep.. but who doesn't?
> One company asked me whether I'd like to join the monitoring team or the container team, to which I replied "why can't I work in whatever team needs me the most, and switch whenever needed?"
Far too many companies are designed as management empires instead of as engineers-as-drivers of change. This means that you are being only hired as a headcount in a reporting chain, not as a versatile engineer that can be help boost a company. They'll impose ineffective policies such as you cannot switch teams before 18 months, or a manager can sabotage your mobility with some reviews. All of this is designed to keep the corporate structure inflexible.
It is a structural problem in most American corporations, that they are unable to get past. Faang, and specifically Facebook, encouraged so much mobility - and it showed in the way they completely smashed larger competitors like Google, Microsoft in the last decade.
> Far too many companies are designed as management empires instead of as engineers-as-drivers of change
Well said.
I'll just say that all companies (at least, large US-based ones) are like that. Every single one of them.
The trick is to have a 'management empire' that's large enough that it spans most of the required functions. That way at least some engineers are able to move inside the fiefdom and not bump heads against some other high level manager's domain.
Can you elaborate on the search for a part time gig? One of my pet theories is that the demand for full time engineers is more of a commitment signal than actually practical, as most people I know only actually work 2-6 hours per day while full-time. So it's rather frustrating that good part time roles don't seem to exist.
Most definitely. Most of my time in FB was spent at the very least making FB a better company. I was solving problems that impacted our users or our engineers. The last year though, not so much. I joined a team that I believed was doing revolutionary work, but as the company's leadership redefined what its goals, the team became vegetative and I was spending most of my time trying to find something meaningful to do.
By comparison, everything I do now improving the company I work at, and at most times has a direct, positive impact on our users and in a smaller way on society
I'll work with whichever team most sounds like you don't want to commit. It takes at least a year to gather enough details about use-cases, issues, expansion opportunities. If the company really needs you to move they will ask you. You sound non-committal.
Also, not sure where in FAANG you had such wide scope. At FAANG either teams are mostly organized by business. For e.g. engineers working on Photos at Facebook, can't suddenly decide they want to work on implementing a feature for container orchestration at Facebook works.
Engineers at these companies are like little startups. Senior engineers are expected to take a general problem, nail down the ambiguity / get consensus, and own the project til launch and after. That includes writing docs, running meetings, getting other people to do stuff for you (approvals, coding), writing code, testing, and ops/oncall work. In this way, the role requires "vertical flexibility" - a lot of jobs in one product. It's not "horizontal flexibility" - being a programmer in a bunch of different projects. That's the general gist of it, but I suppose everything can vary given how big these companies are.
Still, we like to speak of all these companies in the same breath, but I feel like unless you worked at a few of them, it's hard to say what the actual commonalities/differences are.
I appreciate your feedback. I don't think I'm non-committal, more like afraid of being boxed into a too-small domain.
The last sentence is factually incorrect. During my time at FB I contributed code to the container solution, the Jenkins-equivalent, the network routing layer, the bare-metal-provisioner, the monitoring solution and even wrote a feature for the website. I identified a problem, parlayed with the owning team, and shipped that feature. This was the best part IMO about working at FB.
engineers working on Photos at Facebook, can't suddenly decide they want to work on implementing a feature for container orchestration
If they find a manager on the container orchestration team with open headcount who wants to hire them, there isn’t much that can stop them from moving.
The heads of the subdivisions of the company “own” their smaller units, and the units own the people. I think of it as feudal governance. “Sharing” people ultimately makes the overlord look weaker.
Have you considered working at a tiny company? Any company with less than 5 engineers will let you do everything. And if you're senior enough, probably most with less than 50.
I bumped into them when looking arouns. During the interviews you could tell the CTO had a huge backlog of juicy items that had a healthy mix of "things I have a clear idea of how to deliver" and "areas I'd like to learn". The fact that the people seemed very nice and the company was actually doing good to the world sealed the deal for me.
A.S --> E.A, no? :)
I decided to abstract away the URL part as it wasn't easily explainable and not important to the story. I figured the JSON-in-JSON part is interesting enough.
Anyway, the resulting memdump with many \\s remains my most audience-engaging slide to date, and figured out the non-company audience deserves to know.
Good times.
You're fully right! I added them both - E.A. was the original toolmaker, and A.S. worked more down the chain. He definitely was the person who walked me through the finer points of retrieving the data.
I joined the team long after this was in production, but I can testify that the service has a lot of moving parts and attributing the reliability / efficiency costs for a specific issue was challenging.
The real formula we used to order servers was more complex than this, and included regional distribution, requirement peaks etc. I can expand more on that process if this is interesting.
However, for the context of this post, this crude approximation suffices IMO
