5 ms·

If seniority and experience do not add up for the majority then it makes software engineering a very dicey proposition. A civil engineer who has built 10 bridg

by throw2016 8y ago

If seniority and experience do not add up for the majority then it makes software engineering a very dicey proposition. A civil engineer who has built 10 bridges or a doctor with hundreds of operations behind them is much more valued than those entering the field. Why would this not apply in software, surely someone who has built tons of products has valuable experience or is there some other factor at work that is devaluing experience? This will also impact decisions to study more as that shortens potential career time, if this is the case then for those choosing streams in engineering maybe choosing another is a more rational decision.

rb808 8y ago
> If seniority and experience do not add up for the majority then it makes software engineering a very dicey proposition. Yes it is. Look out there now at the huge "shortage" of software developers. Meanwhile the 50+ yo IBM guys laid off here will struggle to ever find computer work again.
henryfjordan 8y ago
I think a lot of this stems from the way Software Development, as a practice, is evolving almost as quickly as Computer Science is (or at least there is a perception that it is evolving). Bridges are built largely the same way as they were 100 years ago. Software built today looks different from software built 10 years ago. So when a hiring manager sees a software engineer with 25 years of experience, they can basically ignore the first 10-15 years as irrelevant. Imagine someone who has spent the last 25 years learning everything there is to know about SQL Databases. They aren't going to do very well in a lot of environments today with NoSQL all over that have only been around en masse for ~10 years. Maybe that hiring manager is wrong. Maybe he's not. The engineers with 5 years experience have the same keywords the hiring manager is looking for on their resume as the engineer with 25 years experience. Maybe they aren't really as adept, but since we seem to be unable to really get a good reliable measure on skill, the difference between those engineers looks very small on paper. The project is likely to turn out the same at the end of the day anyway. So when you do the math at the end of the day, the more junior engineers look like a better deal (and they really might be).
- marshray 8y ago
  > Imagine someone who has spent the last 25 years learning everything there is to know about SQL Databases. They aren't going to do very well in a lot of environments today with NoSQL Baloney.
- madengr 8y ago
  Bridges today are not built like 100 years ago. The modern ones seem to collapse more often. The same can be said of software. It seems normal today to ship bug ridden shit. Not so 25 years ago.
umvi 8y ago
Because it's difficult to measure software engineering competence unless you were involved with a very high visibility project? Most software engineers work on proprietary code that no one is allowed to examine. So you have no idea if the principal engineer you are about to hire is really good at his craft or not because you cannot examine his prior art, it being proprietary to his previous company.
conanbatt 8y ago
If that is true, the best punishment you could do to IBM is to fire all their best talent and let other companies use those resources.
downrightmike 8y ago
In the 80s IBM had a team of expert bug smashers they put together. They got the best from different teams and by putting them together, they were magnitudes more efficient and allowed IBM to ship software faster without bugs. But as time went on, hardware was cheaper and bugs were allowed to be released with the expectation that patches will come later to fix it and kick the can down the road. Which is what we have now and why we have frame works like ITIL to manage the incidents to mitigate the issues with the customer and problems that will get bug fixes. There is too much money held up by not releasing and things may get fixed eventually. Released software doesn't have to be good. It mostly has to work. eventually things get fixed, or customers move on, or products get canned. Watson is getting canned because it doesn't provide the value everyone was promised and incremental updates can't kick the problems down the road any further.

rb808 8y ago

> If seniority and experience do not add up for the majority then it makes software engineering a very dicey proposition. Yes it is. Look out there now at the huge "shortage" of software developers. Meanwhile the 50+ yo IBM guys laid off here will struggle to ever find computer work again.

henryfjordan 8y ago

I think a lot of this stems from the way Software Development, as a practice, is evolving almost as quickly as Computer Science is (or at least there is a perception that it is evolving). Bridges are built largely the same way as they were 100 years ago. Software built today looks different from software built 10 years ago. So when a hiring manager sees a software engineer with 25 years of experience, they can basically ignore the first 10-15 years as irrelevant. Imagine someone who has spent the last 25 years learning everything there is to know about SQL Databases. They aren't going to do very well in a lot of environments today with NoSQL all over that have only been around en masse for ~10 years. Maybe that hiring manager is wrong. Maybe he's not. The engineers with 5 years experience have the same keywords the hiring manager is looking for on their resume as the engineer with 25 years experience. Maybe they aren't really as adept, but since we seem to be unable to really get a good reliable measure on skill, the difference between those engineers looks very small on paper. The project is likely to turn out the same at the end of the day anyway. So when you do the math at the end of the day, the more junior engineers look like a better deal (and they really might be).

marshray 8y ago
> Imagine someone who has spent the last 25 years learning everything there is to know about SQL Databases. They aren't going to do very well in a lot of environments today with NoSQL Baloney.
madengr 8y ago
Bridges today are not built like 100 years ago. The modern ones seem to collapse more often. The same can be said of software. It seems normal today to ship bug ridden shit. Not so 25 years ago.

umvi 8y ago

Because it's difficult to measure software engineering competence unless you were involved with a very high visibility project? Most software engineers work on proprietary code that no one is allowed to examine. So you have no idea if the principal engineer you are about to hire is really good at his craft or not because you cannot examine his prior art, it being proprietary to his previous company.

conanbatt 8y ago

If that is true, the best punishment you could do to IBM is to fire all their best talent and let other companies use those resources.

downrightmike 8y ago

In the 80s IBM had a team of expert bug smashers they put together. They got the best from different teams and by putting them together, they were magnitudes more efficient and allowed IBM to ship software faster without bugs. But as time went on, hardware was cheaper and bugs were allowed to be released with the expectation that patches will come later to fix it and kick the can down the road. Which is what we have now and why we have frame works like ITIL to manage the incidents to mitigate the issues with the customer and problems that will get bug fixes. There is too much money held up by not releasing and things may get fixed eventually. Released software doesn't have to be good. It mostly has to work. eventually things get fixed, or customers move on, or products get canned. Watson is getting canned because it doesn't provide the value everyone was promised and incremental updates can't kick the problems down the road any further.