I enjoyed reading this. It could be because I'm thinking of doing more of system/network programming (and learning Zig). I've spent the last 6 years in the JavaScript land and bored of yet-another-bundling or SPA-like pattern.
So there's hope that with consistency and patience, one could build expertise in a totally different area
Depends on the use-case, but if your product is <14 month lifecycle App/shovel-ware, than go JS for the labor compatibility... Yet if you are hitting >40k concurrent users, the options winnow down fairly quickly.
I'm also interested in more low level or systems programming, though I am coming from a mostly backend/system integration background. I feel like a roadblock is that I am self taught, and though I have been doing software engineering professionally for 15 years and software as a job for 20, I still can't call myself an engineer legally. I certainly know I can do the work, but I worry about hiring being wary of a lack of credentials as a legal liability for lower level stuff.
I would love to hear people's stories of interesting jobs they've gotten without a degree in this space.
Thanks, it is inspiring, And it seems like I'm on the same way of that transition, Here is my individual expirment database for learning db internals and rust..
> I was unhappy with this type-casting so I held out while unemployed and continued to write posts and host virtual hackweeks messing with Postgres and MySQL. I started the first incarnation of the Software Internals Book Club during this time, reading Designing Data Intensive Applications with 5-10 other developers in Bryant Park. During this time I also started the NYC Systems Coffee Club.
> I also wanted to cover what it's like coming from engineering management and founding companies to going back to being an individual contributor. (Spoiler: incredibly enjoyable.)
I've done the IC to engineering manager back to IC thing and it is indeed a huge relief to learn that it's OK to do that. My favorite piece of writing on that is The Engineer/Manager Pendulum by Charity Majors: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
Charity makes a very convincing case that it's OK to swing from manager to IC and back again several times over the course of your career and that doing so will make you more effective at both of those things.
> But my background kept leading hiring managers to suggest putting me on cloud teams doing orchestration in Go around a database rather than working on the database itself.
This is extremely annoying. This also means if your first job is doing X, it is very difficult to break into Y even if you know quite well about Y, and even have side projects. I have tried attaching cover letters indicating even if my current experience is in X, I am quite familiar with Y, to no luck. (No one reads those stuff).
On a similar note: I've been listening to various podcasts with Allan Judd for probably more than 10 years now. It's amazing to see someone go from a FreeBSD docs contributor and talented systems administrator to C programmer and ZFS developer.
You have to have serious motivation to not just stay with what you know, but it's a nice kick in the butt to the rest of us to see that it can be done, with you put in the work.
Watching Eaton's journey online was very inspiring but sadly I have also seen a lot of people doing this to no avail. This is eerily similar to how musicians do busking until they got noticed by a record label.
My experience (as a non-CS person) has been that aside from where there is a very large maths component which might block people without further academic-style study (and I wouldn't necessarily even count ML in that, since the maths needed for much of ML is relatively low level, it's certainly not graduate school level understanding maths), there are relatively few areas of software which have high barriers to entry in actually doing stuff - where the barriers are are people willing to take a risk on letting you have a go. That's usually much much easier once you're in a company than if you're applying for a role from the outside.
Every time I've felt like I didn't understand something and felt overwhelmed at the scale at a task, 3-6 months down the line of throwing myself at the problem and trying to understand it, I've realised it's not as hard and part of the barrier was just the unfamiliar terminology and unfamiliar tools. Sure, there is a degree of needing to learn new stuff - which is true in any job and in life - to do new things. But those barriers are not normally insurmountable. That's been true for me in basically every area. It is also why I'm fairly willing to give people a chance, so long as they are able to demonstrate some knowledge which would be able to transfer.
Great story! I always like to tell developers that they can do anything if you just stick to the fundamentals. It's not such a big mountain as it seems!
The type-casting part is relatable. It definitely feels like we're all being pigeon-holed by hiring managers and ATS systems that categorize us and rank us by keywords and work history. It can sometimes be quite difficult to switch from something like web development to embedded to databases. Good on you for breaking through.
I'm also looking to break into databases. But despite having worked on database libraries, general programming experience, and years of designing and operating systems using databases... there's at least hundreds of people who have been working in databases for years longer and getting one's foot in the door that way is tricky.
Keep sharing your passion, that seems to really help stand out. Not all of us might be in a position to found a company or run a user group in a major city (if it doesn't already exist)... but we can write blogs, attend those meetups, give talks, and help each other out on projects.
This is the first time I have ever heard the term “database developer” to mean a developer of the database internals, of the database engine itself.
Every other use I have ever come across has meant the development of the databases themselves, the file in which data is stored in a relational (and recently, non-relational) manner.
Because when we talk about “a database”, we are almost never talking about the engine that works with one, we’re talking about the file that holds all the data. The former is invariably called a “database server”.
Wouldn’t a much more accurate and subject-separate term have been “database engine developer” or “database server developer”? That alone, I think, could have reduced or even eliminated a lot of confusion.
And no, not a newb: working with computers since 1982, on the Internet since 1988, on the web since 1992, and in the IT industry since 1997. In the English-speaking world, too.
An inspiring story.Recently made a similar transition from backend development (with some frontend experience) to database development in C, current team am part of manages the authentication aspect. Can truly resonate with this journey on a personal level.
I'm very glad I was able to start my career in startup world where titles don't mean anything and the prevailing attitude was roll up your sleeves and figure it out. No one else is going to solve it. Within my first five years I was doing everything from terminating network cables to managing servers to app development from the database to the various front ends (web and native, later mobile). I've built always on kiosk software. Fitness devices for medical study. I've built device firmware. I've built ML models. And no one ever told me that's not my job.
You're able to learn and grow an incredible amount in environments that don't lock you out of work based on the shape of the cog that the company hired for.
21 comments
[ 3.5 ms ] story [ 41.3 ms ] threadSo there's hope that with consistency and patience, one could build expertise in a totally different area
https://quasar.dev/introduction-to-quasar/
That being said, Erlang/Elixir abstracts most db use-cases with ecto, and has some other incredibly powerful scalable features for sites:
https://www.phoenixframework.org/
* Distributed
* Fault-tolerant
* Highly available
* Hot swapping
Depends on the use-case, but if your product is <14 month lifecycle App/shovel-ware, than go JS for the labor compatibility... Yet if you are hitting >40k concurrent users, the options winnow down fairly quickly.
Have fun =3
I would love to hear people's stories of interesting jobs they've gotten without a degree in this space.
https://github.com/maxnilz/sboxdb
Now, trying to implement a rocksdb-like LSM based storage in modern C++ and call it from the sboxdb, just for refresh my old C++ memory.
That's the spirit! And it worked.
Both are declarative ways of traversing graph-like datasets (DOM nodes vs tabular relations).
I've done the IC to engineering manager back to IC thing and it is indeed a huge relief to learn that it's OK to do that. My favorite piece of writing on that is The Engineer/Manager Pendulum by Charity Majors: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
Charity makes a very convincing case that it's OK to swing from manager to IC and back again several times over the course of your career and that doing so will make you more effective at both of those things.
This is extremely annoying. This also means if your first job is doing X, it is very difficult to break into Y even if you know quite well about Y, and even have side projects. I have tried attaching cover letters indicating even if my current experience is in X, I am quite familiar with Y, to no luck. (No one reads those stuff).
You have to have serious motivation to not just stay with what you know, but it's a nice kick in the butt to the rest of us to see that it can be done, with you put in the work.
Watching Eaton's journey online was very inspiring but sadly I have also seen a lot of people doing this to no avail. This is eerily similar to how musicians do busking until they got noticed by a record label.
Every time I've felt like I didn't understand something and felt overwhelmed at the scale at a task, 3-6 months down the line of throwing myself at the problem and trying to understand it, I've realised it's not as hard and part of the barrier was just the unfamiliar terminology and unfamiliar tools. Sure, there is a degree of needing to learn new stuff - which is true in any job and in life - to do new things. But those barriers are not normally insurmountable. That's been true for me in basically every area. It is also why I'm fairly willing to give people a chance, so long as they are able to demonstrate some knowledge which would be able to transfer.
The type-casting part is relatable. It definitely feels like we're all being pigeon-holed by hiring managers and ATS systems that categorize us and rank us by keywords and work history. It can sometimes be quite difficult to switch from something like web development to embedded to databases. Good on you for breaking through.
I'm also looking to break into databases. But despite having worked on database libraries, general programming experience, and years of designing and operating systems using databases... there's at least hundreds of people who have been working in databases for years longer and getting one's foot in the door that way is tricky.
Keep sharing your passion, that seems to really help stand out. Not all of us might be in a position to found a company or run a user group in a major city (if it doesn't already exist)... but we can write blogs, attend those meetups, give talks, and help each other out on projects.
Every other use I have ever come across has meant the development of the databases themselves, the file in which data is stored in a relational (and recently, non-relational) manner.
Because when we talk about “a database”, we are almost never talking about the engine that works with one, we’re talking about the file that holds all the data. The former is invariably called a “database server”.
Wouldn’t a much more accurate and subject-separate term have been “database engine developer” or “database server developer”? That alone, I think, could have reduced or even eliminated a lot of confusion.
And no, not a newb: working with computers since 1982, on the Internet since 1988, on the web since 1992, and in the IT industry since 1997. In the English-speaking world, too.
You're able to learn and grow an incredible amount in environments that don't lock you out of work based on the shape of the cog that the company hired for.