3 ms·
Software Engineers Solve Problems
- legerdemain 6y agoI know it's a throwaway five-paragraph blog post that's hardly worth picking a bone with, but it's almost never your job as a software engineer to boil the ocean. > 1. Actually, the bug ultimately comes from a third-party program > 2. Hm, it uses a programming language I don’t know > 3. Oh, the bug is in that programming language’s compiler > 4. This subsystem of the compiler would have to be overhauled > 5. And the problem is overlooked by the language specification (1) happens ubiquitously. If you're working at your own leisure, or you have no other options, or, possibly, your project manager is asleep at the wheel, you might try to fix the bug at the source. But in business settings, the best solution is to write a bandaid fix and move on. Broken code sells better than no code because you were too busy volunteering to shave the proverbial yak. (2) is a non-issue, at least for a hazily defined set of popular languages. And it's usually not ignorance of the language that stops you, it's ignorance of its tool chain. (3) + (4) + (5) It's never a bug in the compiler.[1] And if it is, you're not being paid to fix compiler bugs. And if you are, you don't need this pep talk blog post to tell you that it's your job. [1] http://blog.xcski.com/2012/10/08/how-to-debug http://blog.xcski.com/2012/10/08/how-to-debug
- Seirdy 6y agoThis is a classic example of how meeting corporate expectations of a software developer isn't the same thing as being a good software developer. You aren't paid to make good software; you're being paid to make an ROI. That being said, I've heard that the two sometimes overlap.