4 ms·

Hi all, just to clear some misconceptions: - I'm quite well paid here (4x more than my peers) - I have been hired full-time, and get all the company benefits

Hi all, just to clear some misconceptions: - I'm quite well paid here (4x more than my peers) - I have been hired full-time, and get all the company benefits as well. - The work life is great, and I don't work more than 8-9 hours a day. - The manager/director is great and super supportive. - I'm not being exploited by any means :) Kindly upvote so the disclaimer stays on top of the post!

nsoonhui 2y ago
Sorry to be cynical, but the you mentioned that you are very well paid, many times above your peers. But one does wonder how can there is a company who can afford to pay out so much to a junior, and yet completely unable to attract seniors with experience.
- zer0x4d 2y ago
  He says he is paid more than his peers (who are probably not in the tech field). It's entirely possible his 4x pay above his peers is still less than a senior or staff engineer's pay.
underdeserver 2y ago
Yours is an interesting situation. I would suggest the following: 1) Read code and spend an hour a week keeping up with developments in your immediate field. Understand the most used frameworks, learn how they work, what each one's pros and cons are, the lingo, the discussions. 2) Understand what your manager cares about and what he wants from you. Ask him what would be a success and what would be a failure. 3) Make sure you understand and implement best practices. Do you have a golden set? Tests? Monitoring - Do you know how much data runs through your pipeline, what your error rate is? What wakes you up when the pipeline fails in the middle of the night? Who needs to be notified, what are the downstream effects? 4) After you have a couple of projects under your belt - that may already be the case if you've been there for a while - consider hiring an experienced contractor for a week to review your code and architecture. You said you're responsible for hiring, I'm guessing you have a budget for subcontracting. Like with all contracts, make sure you have well-defined scope for what you're asking for.
Joel_Mckay 2y ago
In general, read the NASA workmanship standards guides for wiring/crimps, and failure analysis documentation like tin-whiskers/shock/vibration/ignition. When working in an industrial setting priorities need to shift away from cost optimized garbage people obsess over like chatGPT, and understand when you mess up people may get seriously injured or dead. Understand shell-offshore standards compliance rules, and explosion rated equipment certification process. Also, integrate the safety procedures in place so when accidents do happen people know the steps to enter safe-mode, and who to phone etc. There are a lot of unspoken rules, and corruption is commonplace in many places. To be honest, understand most petroleum related work will be a knock off of Kongsberg and or Rockwell Automation products. There are also dangerous crazies insisting they know something by skimming stolen CVs etc. Consider the clowns that accidentally cut someones arm off naively touching a hydraulic control-system under maintenance (true story.) Inherent safety is the #1 skill you need to work on, catch the worst case failure modes with sanity checks, and user interaction logging for accountability. YMMV, and no I don't work for free... Have a great day, =3
- hinkley 2y ago
  So they don’t have lockout systems on oil rig equipment yet?
  - Joel_Mckay 2y ago
    I can't discuss client specific internals, but some equipment takes 3 days to bring up online. People are fragile, maintenance/inspections need done, and team communication is more important than any lock with a post-it note. People mess up, and other people bear the consequences. The "figure it out as we go crowd" is not welcome... =3
    - hinkley 2y ago
      I'm just learning about lockout systems from convos on the internet, but the idea is you have a device that locks the equipment in shutdown mode. Apparently fairly common in power generation. The hasp (the part the shackle goes into) has multiple holes, and everyone doing maintenance has their own lock, which they all put on while they're in the danger zone. You're supposed to remove your lock when you finish up, but it sounds like sometimes angry phone calls have to be made.
mempko 2y ago
Coding is the easiest part of the job. The hardest part is creating resilient, useful, and beautiful software. I advise the following - Learn the domain you are in deeply. Talk to the experts (not senior engineers, I'm talking about people doing the work) in your company about how the business and industry works. - The interface is the product. Design beautiful interfaces that match people's mental models. A beautiful architecture needs to support these interfaces. If you have poor engineering, it will show through the product via the interface. - All good engineers are good architects and product people. They understand the needs of their users. They understand their psychology. - There might be software patterns for your industry, find them and learn them. TLDR; The coding part is easy, don't seek the senior engineer to get ahead, look for the industry and business experts. Learn how to build products that are impactful for the people using your software and the business. That's how you become a great engineer.

nsoonhui 2y ago

Sorry to be cynical, but the you mentioned that you are very well paid, many times above your peers. But one does wonder how can there is a company who can afford to pay out so much to a junior, and yet completely unable to attract seniors with experience.

zer0x4d 2y ago
He says he is paid more than his peers (who are probably not in the tech field). It's entirely possible his 4x pay above his peers is still less than a senior or staff engineer's pay.

underdeserver 2y ago

Yours is an interesting situation. I would suggest the following: 1) Read code and spend an hour a week keeping up with developments in your immediate field. Understand the most used frameworks, learn how they work, what each one's pros and cons are, the lingo, the discussions. 2) Understand what your manager cares about and what he wants from you. Ask him what would be a success and what would be a failure. 3) Make sure you understand and implement best practices. Do you have a golden set? Tests? Monitoring - Do you know how much data runs through your pipeline, what your error rate is? What wakes you up when the pipeline fails in the middle of the night? Who needs to be notified, what are the downstream effects? 4) After you have a couple of projects under your belt - that may already be the case if you've been there for a while - consider hiring an experienced contractor for a week to review your code and architecture. You said you're responsible for hiring, I'm guessing you have a budget for subcontracting. Like with all contracts, make sure you have well-defined scope for what you're asking for.

Joel_Mckay 2y ago

In general, read the NASA workmanship standards guides for wiring/crimps, and failure analysis documentation like tin-whiskers/shock/vibration/ignition. When working in an industrial setting priorities need to shift away from cost optimized garbage people obsess over like chatGPT, and understand when you mess up people may get seriously injured or dead. Understand shell-offshore standards compliance rules, and explosion rated equipment certification process. Also, integrate the safety procedures in place so when accidents do happen people know the steps to enter safe-mode, and who to phone etc. There are a lot of unspoken rules, and corruption is commonplace in many places. To be honest, understand most petroleum related work will be a knock off of Kongsberg and or Rockwell Automation products. There are also dangerous crazies insisting they know something by skimming stolen CVs etc. Consider the clowns that accidentally cut someones arm off naively touching a hydraulic control-system under maintenance (true story.) Inherent safety is the #1 skill you need to work on, catch the worst case failure modes with sanity checks, and user interaction logging for accountability. YMMV, and no I don't work for free... Have a great day, =3

hinkley 2y ago
So they don’t have lockout systems on oil rig equipment yet?
- Joel_Mckay 2y ago
  I can't discuss client specific internals, but some equipment takes 3 days to bring up online. People are fragile, maintenance/inspections need done, and team communication is more important than any lock with a post-it note. People mess up, and other people bear the consequences. The "figure it out as we go crowd" is not welcome... =3
  - hinkley 2y ago
    I'm just learning about lockout systems from convos on the internet, but the idea is you have a device that locks the equipment in shutdown mode. Apparently fairly common in power generation. The hasp (the part the shackle goes into) has multiple holes, and everyone doing maintenance has their own lock, which they all put on while they're in the danger zone. You're supposed to remove your lock when you finish up, but it sounds like sometimes angry phone calls have to be made.

mempko 2y ago

Coding is the easiest part of the job. The hardest part is creating resilient, useful, and beautiful software. I advise the following - Learn the domain you are in deeply. Talk to the experts (not senior engineers, I'm talking about people doing the work) in your company about how the business and industry works. - The interface is the product. Design beautiful interfaces that match people's mental models. A beautiful architecture needs to support these interfaces. If you have poor engineering, it will show through the product via the interface. - All good engineers are good architects and product people. They understand the needs of their users. They understand their psychology. - There might be software patterns for your industry, find them and learn them. TLDR; The coding part is easy, don't seek the senior engineer to get ahead, look for the industry and business experts. Learn how to build products that are impactful for the people using your software and the business. That's how you become a great engineer.