GNOME 3.8 Is Dropping Its Fallback Mode

[gamerk2]

Yes, actually I will. Lack of discipline that comes with the education is part of the reason GNU, Xorg, and various other projects are in their current states.

Would you want a doctor who never attended Medical School?

Example:

Had you completed a basic Computer Science education track, you'd have taken a Senior level class called Software Engineering.

They teach you the basics about deliverables, requirements gathering, and project management.

Essentially, you learn all the phases of actually developing software from providing time-lines to delivering an installation media.


Hence the problem with Gnome 3. Who gathered the requirements? Who was the customer?

First off, coming from a tech school, I have a VERY low opinion of most Comp Sci curriculums. This article sums up my thoughts rather nicely:

http://www.flounder.com/bricks.htm

That being said, knowing how to do proper design, documentation, and testing is a MUST, and I've found, on the whole, those that are self taught will be severely lacking in at least one of these three key areas. I currently work as a defense contractor, and trust me, you learn very quickly how to document and test code properly. And I haven't even gone into requirements mapping yet (let alone defining what is and is not a requirement).

I've had the benefit of having co-workers who had the time to properly teach me how things work, how to do proper S/W design, and proper testing methodology. Most people don't, and it shows in the code they put out. They do an experimental hack that has a minor performance benefit in a single application, on a single set of H/W, and poof, it gets pulled upstream. Then sites like Phoronix dig up performance regressions, do an investigation, and manhours that could otherwise be spent fixing other more pressing problems are wasted trying to find said regression. Do this enough, and you can easily stall development by months/years due to the neverending hunt for extra performance.

Systems Architect isn't coding. It's building computers and loading operating systems.

Sure it is. Remember, that in systems that are built from the ground up, the System Architects are generally the ones who define all the S/W interfaces, and likely design/test the majority of the initial code base that the system runs on. The software guys take over once the system itself is up and running according to spec. There aren't many pure Software/System guys anymore, unless they work strictly on "application" software.

[BO$$]

First off, coming from a tech school, I have a VERY low opinion of most Comp Sci curriculums. This article sums up my thoughts rather nicely:

http://www.flounder.com/bricks.htm

That being said, knowing how to do proper design, documentation, and testing is a MUST, and I've found, on the whole, those that are self taught will be severely lacking in at least one of these three key areas. I currently work as a defense contractor, and trust me, you learn very quickly how to document and test code properly. And I haven't even gone into requirements mapping yet (let alone defining what is and is not a requirement).

I've had the benefit of having co-workers who had the time to properly teach me how things work, how to do proper S/W design, and proper testing methodology. Most people don't, and it shows in the code they put out. They do an experimental hack that has a minor performance benefit in a single application, on a single set of H/W, and poof, it gets pulled upstream. Then sites like Phoronix dig up performance regressions, do an investigation, and manhours that could otherwise be spent fixing other more pressing problems are wasted trying to find said regression. Do this enough, and you can easily stall development by months/years due to the neverending hunt for extra performance.



Sure it is. Remember, that in systems that are built from the ground up, the System Architects are generally the ones who define all the S/W interfaces, and likely design/test the majority of the initial code base that the system runs on. The software guys take over once the system itself is up and running according to spec. There aren't many pure Software/System guys anymore, unless they work strictly on "application" software.

I think that the standards are a bit different. There are different methodologies when writing code to keep an airplane up compared to writing a game engine. Also there are different productivity rates. Very different productivity rates.