4 ms·

Lots of things surprised me when I first started working as a developer after university, including version control. For me, he biggest surprises were: - progr

Lots of things surprised me when I first started working as a developer after university, including version control. For me, he biggest surprises were: - programming is a team effort - writing (non-code) is important - software is never done - few clever algorithms used in day-to-day work - the complexity comes from aggregation of many simple things, not one complicated thing https://henrikwarne.com/2012/08/22/top-5-surprises-when-starting-out-as-a-software-developer/ https://henrikwarne.com/2012/08/22/top-5-surprises-when-star...

gravypod 10y ago
What I've never seen shown well in a class is how to maintain software, well, over time. That's something that nothing has tackled. I've got a few ideas for how a class like that should be run, but no way to implement them. It's also important to teach students how not to prematurely optimize, how to find places to optimize, how to use abstraction, and a lot of other things that just are kind of shown and glossed over.
- douche 10y ago
  Is there really a way to teach this other than through the school of hard knocks? I'm really don't know, I feel like I've just gotten better at it as time goes on and experience accrues.
- amelius 10y ago
  > It's also important to teach students how not to prematurely optimize Except if you need a certain level of performance. It would be silly to write a million lines of code to find out that you could never reach the level of performance that was actually required. But in general you are right. I'd like to add that perhaps the most difficult aspect of software engineering is a situation in which specs change all the time. This happens a lot during prototyping, and afterwards, when a prototype has been promoted to a product.
  - khedoros 10y ago
    If you need to maintain a certain level of performance, and the system has early indications that you won't be able to reach that by continuing with the current implementation, then that's hardly "premature" optimization. When people use that phrase, they're usually talking about the nit-picking, obfuscation-inducing stuff that'll get you a 3% increase in speed, that you'd generally do at the end of the development cycle.
  - gravypod 10y ago
    I've never seen a large project completed without either a comprehensive test suite or prototyping. That's why I think premature optimization is bad. We should be testing as we go. We also all understand the limits of our hardware and our abstractions we are applying to the project at hand. If we should be considered professionals we need to prove it by being able to reason about our systems. We should be able to tell beforehand what abstraction is appropriate for the project. That is the knowladge that must be taught.
- dozzie 10y ago
  > What I've never seen shown well in a class is how to maintain software, well, over time. Because you need a long-living project, and such projects are (a) expensive and (b) rare if you mean them to be thrown away. University is not predisposed to carry those out, thus it's industry's job to teach programmers how to do that. Universities are well-suited for teaching different things, which are very difficult to pick up working in industry alone.
Yhippa 10y ago
> - few clever algorithms used in day-to-day work With amount of time we spent on Big-O and multiple classes involving algorithms I thought that if I ever had to do this professionally I would spend all day cooking up all sorts of cool algorithms involving recursion and graphs. It turns out that the biggest fight I have in my day job is not that but herding people to pump out readable code that is relatively performant.

gravypod 10y ago

What I've never seen shown well in a class is how to maintain software, well, over time. That's something that nothing has tackled. I've got a few ideas for how a class like that should be run, but no way to implement them. It's also important to teach students how not to prematurely optimize, how to find places to optimize, how to use abstraction, and a lot of other things that just are kind of shown and glossed over.

douche 10y ago
Is there really a way to teach this other than through the school of hard knocks? I'm really don't know, I feel like I've just gotten better at it as time goes on and experience accrues.
amelius 10y ago
> It's also important to teach students how not to prematurely optimize Except if you need a certain level of performance. It would be silly to write a million lines of code to find out that you could never reach the level of performance that was actually required. But in general you are right. I'd like to add that perhaps the most difficult aspect of software engineering is a situation in which specs change all the time. This happens a lot during prototyping, and afterwards, when a prototype has been promoted to a product.
- khedoros 10y ago
  If you need to maintain a certain level of performance, and the system has early indications that you won't be able to reach that by continuing with the current implementation, then that's hardly "premature" optimization. When people use that phrase, they're usually talking about the nit-picking, obfuscation-inducing stuff that'll get you a 3% increase in speed, that you'd generally do at the end of the development cycle.
- gravypod 10y ago
  I've never seen a large project completed without either a comprehensive test suite or prototyping. That's why I think premature optimization is bad. We should be testing as we go. We also all understand the limits of our hardware and our abstractions we are applying to the project at hand. If we should be considered professionals we need to prove it by being able to reason about our systems. We should be able to tell beforehand what abstraction is appropriate for the project. That is the knowladge that must be taught.
dozzie 10y ago
> What I've never seen shown well in a class is how to maintain software, well, over time. Because you need a long-living project, and such projects are (a) expensive and (b) rare if you mean them to be thrown away. University is not predisposed to carry those out, thus it's industry's job to teach programmers how to do that. Universities are well-suited for teaching different things, which are very difficult to pick up working in industry alone.

Yhippa 10y ago

> - few clever algorithms used in day-to-day work With amount of time we spent on Big-O and multiple classes involving algorithms I thought that if I ever had to do this professionally I would spend all day cooking up all sorts of cool algorithms involving recursion and graphs. It turns out that the biggest fight I have in my day job is not that but herding people to pump out readable code that is relatively performant.