You provide a start and end point and desired distance. It generates one-way or looped walking/running-oriented routes. I’m not the creator, I just use it occasionally.
For me, this sounds like a developer with a lot of potential. You realized your weaknesses and want to improve. That's a big step forward.
To improve, you need to work on projects with more senior developers.
Few things that work for me well:
1. Talk with a senior person about everything you are going to do. How are you going to architect and implement stuff. You will learn a lot just by talking with smart people.
2. Have all your code reviewed by a senior person. It's good practice to do code reviews anyway.
3. Iterate quickly. Preferably, submit your code for review every day. This way you will get immediate feedback and can improve rapidly. I'm even often submitting empty classes and methods just to outline data flow and overall design.
A lot of companies are focusing on hiring "short fat" engineers. Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
> Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
This is what DevOps is _supposed_ to be but often not what "DevOps Engineers" are hired to be. In my experience most companies hire DevOps Engineers that are one of two things:
1) Sysadmins that also know Python and whichever public cloud dominates the vertical the company operates in
2) Developers that don't actually develop but spend all of their time managing CI/CD pipelines, SCM, JIRA, etc.
In either case their roles are obviously secondary to the developers that build actual solutions; they are the mechanics for the software engineers, which inherently means that their contribution to the value stream is not holistic and it's just another way of enforcing the traditional dichotomy between people that build solutions (developers) and people that keep them from falling over (operations).
I've held the title of "DevOps Engineer" at least once professionally and when I would talk to recruiters or new employers about a software engineering position they'd often ask me what "got me into DevOps" or why I'm trying to "get back into coding". If you know and like working with dev tools and infrastructure then my advice to you is to be a Software Engineer that does DevOps, not a "DevOps Engineer".
Some would see this as a cynical take, but I’ve experienced it so many times, and am feeling such burnout from it that I started pondering this week if I’d be better served applying directly to developer roles instead of anything to do with DevOps; seems no one but the most highest of highly functioning teams seem to grok it. Wonder if that makes me a cynic. Would a cynic admit to being a cynic? Probably.
Anyway.
Nice little coincidence seeing your comment suggesting exactly the same thing. Of course, google just calls those people “SREs”...which in the best of worlds is a “Site Reliability Engineer”, in past orgs though it’s really meant “Sometimes Responsible for Everything”
I don't think it's cynical at all... it's just an unfortunate reality. New things come along and people try to fit them into existing frameworks. Words' meanings evolve over time. People that don't actually do technical work often end up being responsible for placing and managing the people that do; sometimes their notions of roles and responsibilities don't align with ours.
> I’ve experienced it so many times, and am feeling such burnout from it that I started pondering this week if I’d be better served applying directly to developer roles instead of anything to do with DevOps
I, too, am glad to see that I'm not the only one that's had this experience. I wish you the best of luck in "breaking the cycle". Hang tough!
"Full stack" (for whatever definition) is valued because it cuts down on coordination costs, but you may run into limits of what you can expect one person to know. Interestingly, as I've had to hire some "skinny" specialists, my Kanban board has gotten wider to coordinate between them.
Agree - most job postings I see call for experience with an ever-increasing number of disparate technologies. And full-stack web development necessitates it until you've grown the team to a large size.
yes it's true. as someone who's a generalist, every interview I've been to asks me very specific things about one programming language / tech stack. Even though I'm underpaid, I enjoy continuing doing my "short fat" engineering at my current job getting to touch many technologies and focusing on solving the problems at hand rather than specializing in one.
Just use PostgreSQL. You can get really really far with just an SQL database and few indexes. It's enough for 99% of projects.
This has two big advantages:
1. PostgreSQL is a reliable, high performant database, which has been proven over time. So you are not going to deal with weird issues and can focus on your project.
2. You will learn SQL which you are going to use throughout your whole career.
As a team of just me with not much savings, trying to make something that may grow quickly (1-10s of TBs), I cant afford to scale up from the get-go. I need to be able to scale out first. It doesn't seem Postgres is conducive to that. AFAIK clustering or sharing is not yet offered by the core.
In addition, I need to look more deeply into postgres but its considerations for things such as lazy replication (unreliable connections or offline/mobile users) don't seem any less complicated than other options.
I don't know your business but scaling to 1TB of data (not just files, but actual rows in a database) seems weird. Feel free to prove me wrong (I'm just some person on the internet, after all), but I've seen many startups fool around with over architecting instead of building features users want.
"So, you’re building the next unicorn startup and are thinking feverishly about a future-proof PostgreSQL architecture to house your bytes? My advice here, having seen dozens of hopelessly over-engineered / oversized solutions as a database consultant over the last 5 years, is short and blunt: Don’t overthink, and keep it simple on the database side! Instead of getting fancy with the database, focus on your application. Turn your microscope to the database only when the need actually arises, m’kay! When that day comes, first of all, try all the common vertical scale-up approaches and tricks. Try to avoid using derivative Postgres products, or employing distributed approaches, or home-brewed sharding at all costs – until you have, say, less than 1 year of breathing room available."
I just read the original article my self before seeing your post. The last bit about "sharding" by partitioning your db from the start helped alleviate a lot of my concern I think. All my apps data doesn't actually need to be in the same DB for 90% of my use case (userid in range -> db x).
You may be able to setup a multi tenant db. I've done this in the past. A new schema was created for each tenant. It worked well. It never got to the size where it had to scale out. So not sure how easy it would have been to move to multiple databases.
If your business grows so quickly that one Postgress instance can't cope, by that time hopefully you should have enough revenue (or investors) to add a few read replicas.
Also, are you planning on storing large blobs in the database? If so, consider storing them in a blob store (e.g. S3) and only storing their path in the DB.
think something like google keep or trello or airtable. Its just a lot of text/json. Its in a db and not blobs or object store due to sync, filtering, tagging, reporting ..... larger assets(img) will be in an object store
Maybe its not supposed to be in a DB, but using my export of google keep as a guide on average my larger files are 10-20kb of json. x that by 1000 for unlimited* storage and x that per user you're over 1 TB.
Even in that case postgres will still work and there will be enough time to scale up manually. But from the perspective of architecting something on this scale or beyond I made my original post.
And so maybe I am over architecting then both of yours advice about pg still applies. (you guys are ultimately right, practically)
That’s upside.