I came to think that many, many times deep understanding an elegant, well crafted solution are just an exercise of style, not really need...
I came to think that many, many times deep understanding an elegant, well crafted solution are just an exercise of style, not really needed, and not actually needed (often a waste of time). And __DON'T__ get me wrong on this: I love understanding how things work and write beautiful code. The thing is: you're working for a company, and let's say you're using $language and $framework. You have the deadline in a month (or two months, or n months). You come across a problem. And here the kind of company you're working for makes the difference. If you're working for a small or medium sized company, maybe it's just better to google an answer and do some copy-paste from stack overflow. Small-sized companies have more interest in getting things done than anything else. Typically. If otherwise you're working for a big company, you're developing code which will be used by thousands (millions?) of users and your company has (or wants to establish) a role in the open source industry, then you sit down and examine the bug, you examine the stack traces, you fix it, and maybe submit a patch. Not only that, you also want to make your code as fast as it can possibly be. Because saving 2% execution time on two servers may not be that interesting if you have to spend three weeks, but saving execution time on 300 or 400 servers (or more)... Well, that matters. As many other said, it's all about compromise. You may want to consider applying for a position to $big_company.
Posted by znpy on Jun 7, 2015, 6:49 PM
Tags
Related issues
- [BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
- Feature Request: Auto-resume CLI session when usage limit resets
- Please deobfuscate the Python
- [Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
- # 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
- [FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Raise real-world problems, find people facing the same issue, and discuss solutions.6,000 issues0 comments
reliability (Software)
[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
Feature Request: Auto-resume CLI session when usage limit resets
Please deobfuscate the Python
[Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
# 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
[FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Admin Materials and Surfaces
AMD Support
I came to think that many, many times deep understanding an elegant, well crafted solution are just an exercise of style, not really need...
I came to think that many, many times deep understanding an elegant, well crafted solution are just an exercise of style, not really needed, and not actually needed (often a waste of time). And __DON'T__ get me wrong on this: I love understanding how things work and write beautiful code. The thing is: you're working for a company, and let's say you're using $language and $framework. You have the deadline in a month (or two months, or n months). You come across a problem. And here the kind of company you're working for makes the difference. If you're working for a small or medium sized company, maybe it's just better to google an answer and do some copy-paste from stack overflow. Small-sized companies have more interest in getting things done than anything else. Typically. If otherwise you're working for a big company, you're developing code which will be used by thousands (millions?) of users and your company has (or wants to establish) a role in the open source industry, then you sit down and examine the bug, you examine the stack traces, you fix it, and maybe submit a patch. Not only that, you also want to make your code as fast as it can possibly be. Because saving 2% execution time on two servers may not be that interesting if you have to spend three weeks, but saving execution time on 300 or 400 servers (or more)... Well, that matters. As many other said, it's all about compromise. You may want to consider applying for a position to $big_company.
Comments (0)
No comments yet. Start the discussion.