4 ms·
It makes sense on all levels. Pay is not correlated with how hard your job is. It's correlated with how large of an impact you have on the business. It's rea
by nightski 8y ago
It makes sense on all levels. Pay is not correlated with how hard your job is. It's correlated with how large of an impact you have on the business.
It's really easy to have $1M+ (or basically very large) impact on a business by making data more accessible and providing solid analysis.
On the flip side, it's really hard to have a really large impact writing low level embedded code.
The reason for that is because since it is a well defined problem (control this hardware, send data from here to there) there is not a lot of room for creative flexibility. So it's hard to differentiate yourself above others (even though very technical people know that the quality of low level code can vary dramatically, this often isn't reflected in the success of the business).
At the end of the day I always ask myself, is what I am doing driving business value for my clients. If not, I try to reframe what I am working on so that is the case.
- deleted 8y ago[deleted]
- jcoffland 8y ago> even though very technical people know that the quality of low level code can vary dramatically, this often isn't reflected in the success of the business I would rephrase that as the quality of low level code is not often recognized as having a huge impact on the success of the business but when low level code goes wrong it can have very costly negative effects which ripple up through the company. The usual manifestation is a buggy product with many layers of hacked together bloat. Low level code often does not get the attention it deserves because the higher ups don't understand it.
- solarkraft 8y ago> it's really hard to have a really large impact writing low level embedded code Like the person designing the foundation doesn't have a large impact on the stability of a tower?
- nightski 8y agoYou are missing my point. The point is that the impact one has writing embedded software is largely defined in the spec. Other than perfectly meeting that spec, there is not a lot of room to go above and beyond and create extra value. I'll admit I am not a 30 year veteran in embedded development, but I did spend a few years in the field. Embedded development is very time consuming because it's generally so critical to get right and keep bugs to an absolute minimum. Which is also why it's important to keep it as simple as possible. This inherently limits how creative one can get.