4 ms·

If "technical stuff" is your primary interest, you should probably consider changing jobs. If technical proficiency was all that important to your employer, yo

If "technical stuff" is your primary interest, you should probably consider changing jobs. If technical proficiency was all that important to your employer, you probably wouldn't be in position you're in.

Simon_ORourke 2y ago
> If "technical stuff" is your primary interest, you should probably consider changing jobs. This 100%. It seems that you're doing things proficiently enough to keep your job, but just want to improve your capabilities as a coder. It's going to be difficult without a proper structure or mentors around you. So you've to make a decision whether you'd prefer to stick with the role and get slowly better over time using blog posts and AI reviews, or jump in the deep end and get another role in a more tech industry aligned company. And if you decide to jump to another role, just be aware that you're going to spend 3 to 6 months panicking about whether you're in over you head, and probably won't get "comfortable" in the role for a year.
- l00sed 2y ago
  "AI reviews" is actually a really interesting use-case that I hadn't considered-- but makes so much sense. I feel like it might be good to use Cursor or another AI assistant just for the purpose of suggesting improvements rather than a way to code quicker.
donall 2y ago
Strongly agree. I have been doing data engineering for 14 years and, in my experience, new grads need a lot of on-the-job training. There are a lot of real-world problems (e.g. consistency problems, scale problems, distribution problems) that benefit from a little bit more than just theoretical knowledge. A lot of data systems are full of problems because they were designed and implemented by inexperienced people. People don't know what they don't know and there are a lot of teams that say things like "oh yeah, this takes 3 days to run because it's pretty big" or "we release code daily but it would be too expensive to re-process past data to fix bugs" or even "what's a schema?". YMMV, though. Some data engineers are writing basic SQL or playing with Azure Data Factory and there isn't too much complexity. Read Designing Data Intensive Applications. If that sort of thing resonates with you then find someone to work with who has experience with those kinds of problems! [Edit: no disrespect to ADF! Just pointing out that the data engineering discipline is broad and different practitioners will have different expectations of complexity]

Simon_ORourke 2y ago

> If "technical stuff" is your primary interest, you should probably consider changing jobs. This 100%. It seems that you're doing things proficiently enough to keep your job, but just want to improve your capabilities as a coder. It's going to be difficult without a proper structure or mentors around you. So you've to make a decision whether you'd prefer to stick with the role and get slowly better over time using blog posts and AI reviews, or jump in the deep end and get another role in a more tech industry aligned company. And if you decide to jump to another role, just be aware that you're going to spend 3 to 6 months panicking about whether you're in over you head, and probably won't get "comfortable" in the role for a year.

l00sed 2y ago
"AI reviews" is actually a really interesting use-case that I hadn't considered-- but makes so much sense. I feel like it might be good to use Cursor or another AI assistant just for the purpose of suggesting improvements rather than a way to code quicker.

donall 2y ago

Strongly agree. I have been doing data engineering for 14 years and, in my experience, new grads need a lot of on-the-job training. There are a lot of real-world problems (e.g. consistency problems, scale problems, distribution problems) that benefit from a little bit more than just theoretical knowledge. A lot of data systems are full of problems because they were designed and implemented by inexperienced people. People don't know what they don't know and there are a lot of teams that say things like "oh yeah, this takes 3 days to run because it's pretty big" or "we release code daily but it would be too expensive to re-process past data to fix bugs" or even "what's a schema?". YMMV, though. Some data engineers are writing basic SQL or playing with Azure Data Factory and there isn't too much complexity. Read Designing Data Intensive Applications. If that sort of thing resonates with you then find someone to work with who has experience with those kinds of problems! [Edit: no disrespect to ADF! Just pointing out that the data engineering discipline is broad and different practitioners will have different expectations of complexity]