4 ms·

If that's any consolation, stuff like Big O almost never comes up in most software jobs. I"d be more worried about these guys writing buggy and unreadable code.

AnimalMuppet 10y ago
I know what Big O is. (Obviously, they're a chain of tire stores - at least, they used to be.) My first job out of school, though, I didn't. I think maybe I learned it around ten years into my career. I've needed it very little.
- rrrjjjqqq 10y ago
  I used to manage a team of devs who looked down on other devs for not knowing what Big O is. I've argued with them more than once that yes, their algorithm is technically more efficient, but the 20 extra network calls they're adding means it's going to perform significantly worse without exponential growth. I'd rather have a person on my team who can develop solutions for the circumstances they're working in over a person that can write perfect, white paper worthy code for spherical cows in vacuums any day.
  - dsacco 10y ago
    I think that's an orthogonal issue. Prematurely optimizing, or inappropriately optimizing code by over-engineering its efficiency is mutually exclusive from knowing how to optimize in the first place. It's a bit of a false dichotomy - you don't have two camps, one which understands optimization and does it too much, and another which doesn't understand it and produces code faster. It's a fair expectation to have developers reasonably cognizant of computer science fundamentals and also to utilize them sparingly and appropriately. In the same way, it's important to understand how microservice architecture works and what its benefits are for scale at a theoretical level, at least. But that does not mean that you split everything into microservices for a GitHub side project or for a SaaS with fewer than 100 active users. When you need the tool, you open your toolbox. But the mere presence of the tool does not mean it will be used. I also don't think it's fair to look down on peers for a lack of education, as long as they are not willfully antagonistic to improving themselves.
- dsacco 10y ago
  The thing with core computer science concepts like Big O is not that you need to know them, but that you typically don't realize how much better your code would be if you did know them (and applied them). I personally have (what I would consider to be a bad) habit of writing a bunch of code with minimal planning upfront, but after it's working I'll review the expected performance of each function and try to optimize as I debug it. There have been times (especially when I'm writing in a new language) where I've written code that works, but missed a spot where it's inefficient and could be significantly improved with a small tweak. The code will run, and in the context of what it's doing it will complete, but it could be made much faster. This has important ramifications if your code is, for example, doing a lot of egress out of AWS, or doing a lot of parsing or data transformation. In situations where the code is not obviously incorrect, it often happens that it's simply not as performant as it could be. It will stay that way, unless a peer reviews the code and spots the inefficiency, or the developer spots it themselves. For small portions of software these individual inefficiencies are not troubling. But there is a real revenue cost to these inefficiencies in production infrastructure if you're doing something more complex than gluing disparate libraries together. I can sympathize with the OP because while I am a big believer in Everyone Gets Code Review (no exceptions), it can be painful for someone to constantly have to fix the same errors over and over again. If the devs on the team in question are motivated to change habits and learn, this won't be a problem. But it could quickly get exhausting to have to fix things on a team over and over again. What will happen if they do not understand e.g. Big O, is the code will work, and every issue will look different to them because they focus on examples, but from the CTO's perspective they'll all be manifestations of the same thing. One will see forest, the other will see trees, and the behavior will be hard to correct. It's also a recipe for low confidence and animosity. I agree with you though that you often don't need this knowledge; i.e. you'll write functioning code without it, and you don't want to prematurely optimize. But you can output better software with fewer unknown unknowns, and Big O is one of them.
  - rrrjjjqqq 10y ago
    I agree that there's a balance between the two. My ideal team is probably a quarter that know core CS concepts and how/when to use them and the other three quarters devs can write good code whether or not they know core CS concepts. The part that makes me frustrated enough to comment on this is that I've found that a lot easier to convince a dev who doesn't know Big O that they need to than it is to convince a dev that does know Big O that it's not always necessary. Convincing is significantly harder if the dev graduated from college in the past 3 years.
iEchoic 10y ago
Big O notation doesn't come up explicitly in conversation often, but the principles come up constantly. You need a fundamental understanding of the time complexity of algorithms to write good software of non-trivial complexity in most domains.
- dsacco 10y ago
  I don't understand why this sentiment gets downvoted so often. The commenter didn't express anything rudely, and it doesn't seem controversial. If you are writing software that is more complex than simply gluing libraries together; i.e. you have to think and plan the functionality out, then yes, the odds are that you will benefit from understanding time complexity at least once somewhere. I feel that saying things related to algorithms invokes an anger towards unreasonable whiteboard interviews these days. No one is claiming you need to memorize algorithm and data structure implementations from scratch (although, for basic things like queues and linked lists you should probably be capable of writing one, even if it requires referencing wikipedia briefly...). We're just saying that a solid understanding of time complexity is generally and broadly very helpful.

AnimalMuppet 10y ago

I know what Big O is. (Obviously, they're a chain of tire stores - at least, they used to be.) My first job out of school, though, I didn't. I think maybe I learned it around ten years into my career. I've needed it very little.

rrrjjjqqq 10y ago
I used to manage a team of devs who looked down on other devs for not knowing what Big O is. I've argued with them more than once that yes, their algorithm is technically more efficient, but the 20 extra network calls they're adding means it's going to perform significantly worse without exponential growth. I'd rather have a person on my team who can develop solutions for the circumstances they're working in over a person that can write perfect, white paper worthy code for spherical cows in vacuums any day.
- dsacco 10y ago
  I think that's an orthogonal issue. Prematurely optimizing, or inappropriately optimizing code by over-engineering its efficiency is mutually exclusive from knowing how to optimize in the first place. It's a bit of a false dichotomy - you don't have two camps, one which understands optimization and does it too much, and another which doesn't understand it and produces code faster. It's a fair expectation to have developers reasonably cognizant of computer science fundamentals and also to utilize them sparingly and appropriately. In the same way, it's important to understand how microservice architecture works and what its benefits are for scale at a theoretical level, at least. But that does not mean that you split everything into microservices for a GitHub side project or for a SaaS with fewer than 100 active users. When you need the tool, you open your toolbox. But the mere presence of the tool does not mean it will be used. I also don't think it's fair to look down on peers for a lack of education, as long as they are not willfully antagonistic to improving themselves.
dsacco 10y ago
The thing with core computer science concepts like Big O is not that you need to know them, but that you typically don't realize how much better your code would be if you did know them (and applied them). I personally have (what I would consider to be a bad) habit of writing a bunch of code with minimal planning upfront, but after it's working I'll review the expected performance of each function and try to optimize as I debug it. There have been times (especially when I'm writing in a new language) where I've written code that works, but missed a spot where it's inefficient and could be significantly improved with a small tweak. The code will run, and in the context of what it's doing it will complete, but it could be made much faster. This has important ramifications if your code is, for example, doing a lot of egress out of AWS, or doing a lot of parsing or data transformation. In situations where the code is not obviously incorrect, it often happens that it's simply not as performant as it could be. It will stay that way, unless a peer reviews the code and spots the inefficiency, or the developer spots it themselves. For small portions of software these individual inefficiencies are not troubling. But there is a real revenue cost to these inefficiencies in production infrastructure if you're doing something more complex than gluing disparate libraries together. I can sympathize with the OP because while I am a big believer in Everyone Gets Code Review (no exceptions), it can be painful for someone to constantly have to fix the same errors over and over again. If the devs on the team in question are motivated to change habits and learn, this won't be a problem. But it could quickly get exhausting to have to fix things on a team over and over again. What will happen if they do not understand e.g. Big O, is the code will work, and every issue will look different to them because they focus on examples, but from the CTO's perspective they'll all be manifestations of the same thing. One will see forest, the other will see trees, and the behavior will be hard to correct. It's also a recipe for low confidence and animosity. I agree with you though that you often don't need this knowledge; i.e. you'll write functioning code without it, and you don't want to prematurely optimize. But you can output better software with fewer unknown unknowns, and Big O is one of them.
- rrrjjjqqq 10y ago
  I agree that there's a balance between the two. My ideal team is probably a quarter that know core CS concepts and how/when to use them and the other three quarters devs can write good code whether or not they know core CS concepts. The part that makes me frustrated enough to comment on this is that I've found that a lot easier to convince a dev who doesn't know Big O that they need to than it is to convince a dev that does know Big O that it's not always necessary. Convincing is significantly harder if the dev graduated from college in the past 3 years.

iEchoic 10y ago

Big O notation doesn't come up explicitly in conversation often, but the principles come up constantly. You need a fundamental understanding of the time complexity of algorithms to write good software of non-trivial complexity in most domains.

dsacco 10y ago
I don't understand why this sentiment gets downvoted so often. The commenter didn't express anything rudely, and it doesn't seem controversial. If you are writing software that is more complex than simply gluing libraries together; i.e. you have to think and plan the functionality out, then yes, the odds are that you will benefit from understanding time complexity at least once somewhere. I feel that saying things related to algorithms invokes an anger towards unreasonable whiteboard interviews these days. No one is claiming you need to memorize algorithm and data structure implementations from scratch (although, for basic things like queues and linked lists you should probably be capable of writing one, even if it requires referencing wikipedia briefly...). We're just saying that a solid understanding of time complexity is generally and broadly very helpful.