How much of the job comes down to deeply understanding the domain/business knowledge and applying SQL?
Posted by throwaway0134hdj@reddit | ExperiencedDevs | View on Reddit | 19 comments
As we know budget controls every aspect of our work, whether we have work as well as what we work on. And getting budget comes down to delivering value to the client. And delivering value to the client comes down to how well you understand the domain/business knowledge. And at least in my case, 90% of the business logic effectively boils to down SQL statements. Such as check if this lookup table contains a value (or generate a value based on what’s in the lookup table), do X but only when Y is true, essentially a chain of lookups with conditional logic.
My question is how much of your job effectively boils down to this? Especially when it comes to what the client values, is the majority of what they appreciate effectively coming down to what could be done in SQL statements?
Thanks
MonochromeDinosaur@reddit
I never build anything without either understanding this myself or having a product person who understands it. What’s the point otherwise, you’re literally coding into the void.
baby-in-the-humidor@reddit
I prefer coding into the void personally. Never know what you'll find out there 🌌
Smallpaul@reddit
I actually never write SQL (or ORM) in my job. I’ve had some CRUD type jobs in the past but a lot more that were not.
throwaway0134hdj@reddit (OP)
If it’s not CRUD then what else is there?
Smallpaul@reddit
Compilers. Games. NLP. Agents. Desktop apps. Interpreters. Device drivers. Developer tools.
I’ve done most but not all of these.
GoodishCoder@reddit
I do my best to keep business logic out of SQL statements
Outside-Storage-1523@reddit
All engineering work relies on how much value you deliver to the client. The more important points are:
- What does "business" mean in this job? Do I want to interact with these clients every day?
- Does this job offer deep, hard engineering work, or something else? Which one do I want?
For example, being a data engineering writing a ton of SQL and writing OS kernels are both "delivering to a client" and for the DE business logic = Understanding a ton shit of business jargons such as DAU, MAU, ARPU, etc., while the Kernel "business logic" = Understanding how applications run on the kernel and how to enable the best performance and support from the kernel, etc.
They are both "business", which one do you want? That's the real question.
My job basically boils down SQL queries as I work as a DE. I deeply resent my job as I believe DE in general is a very bad job for true engineers, because it does not provide the environment for deep, hard engineering work. But some people do enjoy it, so it's just a personal taste and I won't see which one is better.
throwaway0134hdj@reddit (OP)
I agree, my job is effectively a DE, it’s not what I signed up for but sorta what the business required and I didn’t have a lot of other work options so I’ve been doing this. Effectively piping data from point A to B and running a bunch of SQL code against the data. Yes, it doesn’t feel like it’s engineering, feels more like advanced data analyst at times, stakes are very low I could screw up royally and still have this job. Whereas I think genuine software jobs there is a lot more to do than just moving data around and transforming it, and the stakes are a lot hire and audience is bigger. My work supports enterprise processes so only a handful of ppl actually use it.
Outside-Storage-1523@reddit
Yeah, I agree. I'd encourage you to find a better job without quitting this one. Economy is in a dump right now...
throwaway0134hdj@reddit (OP)
Yes I want sth else, but also trying to be careful with moves in the current client. Just is boring but also somewhat stable and predicable. I’d also like to avoid toxic teams as I’ve worked on a few before. As any sort of place that does stacked ranking or believes in putting colleagues in competition.
I like wouldn’t accept anything below $150K/yr, as the stress I incur wouldn’t be worth it otherwise, I’m aiming for $200K.
ZukowskiHardware@reddit
Most of it. We ship understanding, not code.
PoopsCodeAllTheTime@reddit
Um… all of it?
Lately I’ve been dealing with data sync layer, the apps literally do not work without it, it’s 100% database internals
throwaway0134hdj@reddit (OP)
When you say data sync are you literally referring to keeping two databases in sync with each other. Like ensure that what’s in source A is also in source B?
potatolicious@reddit
This varies greatly depending on what your job is and the nature of your product.
There are for example lots of apps that are technically quite simple and just novel assemblages of extremely rote and well-understood technology. In that case yeah, domain knowledge is 90% of the job. A lot of apps are "CRUD for [domain]" and those are definitely cases where domain knowledge trumps technical knowledge.
But a lot of products aren't like that, where the underlying tech is less rote, less standardized, and less well-understood. In those cases a lot more of the job is depth in a particular technical specialty.
Life-Principle-3771@reddit
For me not that much. Just getting data out of SQL is easy, everything you have to do before and afterwards is what is hard
throwaway0134hdj@reddit (OP)
After getting the data out what else is being done that makes things difficult?
Life-Principle-3771@reddit
I mean a lot of things?
First off I have worked on several systems where data was actually stored in an offboard location (usually S3) and simply referenced in a SQL database. So the workflow would be something like:
Query DB for S3 locations + run some other workflow often Spark from my experience that downloads files from these locations, de-serializes, cleans, transforms, and then publishes data to some other location. Even if you don't have something like this I frequently find myself cleaning, transforming, normalizing, or even sorting data after querying.
For example let's imagine that I'm building an analytics engine based on things that you have clicked on when visiting my site.
We capture metrics on all of your clicks in the following columns:
User | Time | Device | Page | Item
As this may be a database with millions of rows (people click a lot) we will have a composite partition key on only user and time. If I want to insert data into my analytics engine grouped by page (say it's stored as just a string url) it's probably better that I just pull all of the user/time data from SQL and then do the page parsing/grouping off of the database or it's going to be a very long/expensive query. Plus I may want to do something like put clicks coming from different pages in different S3 buckets, which I can more easily do here after sorting as compared to making several SQL queries and building individual ETLM jobs.
SoggyGrayDuck@reddit
I recently learned that it completely depends on how the team operates. I highly prefer getting my own specs/requirements. It puts you at such a disadvantage otherwise. You really don't, or even can't, add much value outside pushing code. I thought I would like it, I needed a break but it also sucks being so clueless about how things work. No front end access or any explanation of how the software works.
okayifimust@reddit
In my case, I need to understand it to the degree that I can model it.
Far less for me.
You're brushing over the "do this" part here. And you can dumb down the description of any skilled activity long enough until it looks easy - doesn't mean that that is a useful thing to do.
All of it, if you squint hard enough; very little if you don't.
No, not even if you effectively squint until you're blind, and let "could" do all the heavy listing in the world.
I am writing a third party integration right now. Sure enough, at the end of the day, something gets stored in some database; but the majority of the work, and the logic lies elsewhere - and that ignores the parts where I have to talk to other people, and we have to agree on what needs to happen. And that is far more difficult than getting the code to then do the thing we agreed upon.