What do you mean by skilled admin? Do you mean at rack space or AWS. Otherwise, I can't see how it matters, IT and programming are dead, business and product development rule the future. Everything else is the rest of the IT carcus rotting it's slow disgustingly long death. Good riddance.
I like to act a little unusual in a meeting. Even show some eccentricities. Based on how accepting of odd behavior a company is usually helps me (alleged talented engineer) determine if I want to work their.
I think the problem here is that software engineering is not emphasized enough. Programming, while crucial is a small part of being a successful software developer. The way I see it there are four grades of software professionals. These are scientist, engineers, programmers and support.
These disciplines are often separated from each other. These separations prevent programmers from understanding the career paths of the industry.
The support people do not understand what skills are required to move on to the next level. Software patterns and practices are not terms they hear often and they are unaware of the importance they serve to the programming discipline.
The programmers understand patterns and practices but do not understand formal software engineering. Requirements and test case development, development cycles, defect management, development progress are all part of a larger software engineering discipline. These skills are required to move on to the next level. It's very easy for a programmer to understand deadlines are relative. But it is very difficult for them to prove it. If your car had a clock in the place of a speedometer could you tell me how fast you were going?
Software architecture can serve as a bridge between these disciplines but architects often do not understand how to manage leadership to obtain the technical goals of a project. Project managers run all over the architects in a project because the architects do not have the business / political savvy to play those games. Software engineering as a discipline that gives an architect the tool set to manage not just the technical side of a project but the human / political side of a project.
Scientists are scientists. They are the red headed step-"rock stars" of our era. Scientists bring the world to the next level. Scientists are very passionate about their work and are will to do it often times for very little money. But they stand to gain huge payoffs for a significant contribution to society. I don't know what could be more honorable.
But why does all of this matter, because most computer science majors are not scientists. They are programmers and often times just support people. They are trying to learn something to build a career on. A job in middle America that pays 125K/yr so they can take care of their family, have a nice lifestyle, better computer equipment than their friends and fancy cars to make up for the void of not living out their dreams. But 125K is a tough job to get and a tough job to have.
As far as I know very few universities offer serious software engineering degrees. Most programmers would probably not even major in software engineering simply because they don't understand it is the ticket to their goal. Computer science simply has not given the majority of programmers the necessary tools to make it in the computer industry.
Comments are important. However there are different types of comments each with varying degrees of priority. Comments are primarily code documentation. Code generally starts with some sort of design and design documents are the first stage of code documentation.
Designs don't have to be monolithic war and peace style documents, rather very high level documents describing the purpose of the code. This generally gives future maintainers of developers an idea of the effect changing the code will have on an application.
Class Documentation / API Documentation / Java Docs / Perl Docs /.Net XML Docs are in my opinion are the most important forms of code documentation. I very much enjoy reading articles about programming concepts and designs. But when I am coding, it is the API documentation that I spend most of the time reading. My favorite languages are those which provide a large library of useful classes that I can reuse. perl, php and Java have large online communities that produce reusable library. This has two effects.
Writing such small reusable libraries generally the documentation will be very good. Each reusable library has documentation that allows other programmers to figure out how to use them. This means people writing these libraries are not only good at writing reusable code. They are also good at instructing others about how to use such code. Over time they become experts at documentation and serve as role models for others developer..Net is an example of a large development group accepting these practices and now trying to embrace such strategies. But there is a much more interesting aspect to this.
Developers using these libraries become very good at using libraries. As programmers become more experienced, they progressively become more adept at finding reusable code and being able to make it part of a consistent unified solution. Developers who are practicing these techniques are becoming very good at designing and documenting reusable code. Having this community of code exposes developers to an enormous amount of high quality well documented code. This not only allows them to be more efficient developers, but teaches them to be very efficient designers. These are the people who become the respected technical leaders and in the optimistic case your boss or the senior programmers on the projects for your work. Perhaps you are one of those programmers and other a benefiting from your use of such tactics.
The least import type of code comments are the one or two lines before the while loop. These types of comments document the code at a micro level. At this level you rarely need a lot of comments. In most cases a competent developer requires the ability to decompose the code and this level without a lot of comments. This type of comment is never the less on the forefront of most discussion about code comments. Less experienced developers general can figure out the code is difficult to maintain but may not know exactly why. Not having the experience to point at exactly what makes the code difficult to maintain they assume it lacks sufficient documentation. This argument seems almost immediately logical. Unfortunately there is a flaw in this logic.
Just because code is difficult to maintain or enhance does not indicate poor documentation. I have maintained lots of well documented code that required hundreds of hours of modification to fix simple bugs or implement small changes. Several years ago I was asked by my company to help when a new application was released to our clients. This code met the acceptable requirements for code documentation. Each file had a header with modification history including date and developer information. Comments we also placed liberally throughout the code. This projected resulted in a single release and is currently being rewritten from the ground up. When I was asked to assist with the analysis the code documentation helped us quickly conclude the application would not be a viable replac
Slashdot Mirror
What do you mean by skilled admin? Do you mean at rack space or AWS. Otherwise, I can't see how it matters, IT and programming are dead, business and product development rule the future. Everything else is the rest of the IT carcus rotting it's slow disgustingly long death. Good riddance.
Vision balls and thought boxes are ideas the daily show is made of.
I like to act a little unusual in a meeting. Even show some eccentricities. Based on how accepting of odd behavior a company is usually helps me (alleged talented engineer) determine if I want to work their.
MES?
I think the problem here is that software engineering is not emphasized enough. Programming, while crucial is a small part of being a successful software developer. The way I see it there are four grades of software professionals. These are scientist, engineers, programmers and support.
These disciplines are often separated from each other. These separations prevent programmers from understanding the career paths of the industry.
The support people do not understand what skills are required to move on to the next level. Software patterns and practices are not terms they hear often and they are unaware of the importance they serve to the programming discipline.
The programmers understand patterns and practices but do not understand formal software engineering. Requirements and test case development, development cycles, defect management, development progress are all part of a larger software engineering discipline. These skills are required to move on to the next level. It's very easy for a programmer to understand deadlines are relative. But it is very difficult for them to prove it. If your car had a clock in the place of a speedometer could you tell me how fast you were going?
Software architecture can serve as a bridge between these disciplines but architects often do not understand how to manage leadership to obtain the technical goals of a project. Project managers run all over the architects in a project because the architects do not have the business / political savvy to play those games. Software engineering as a discipline that gives an architect the tool set to manage not just the technical side of a project but the human / political side of a project.
Scientists are scientists. They are the red headed step-"rock stars" of our era. Scientists bring the world to the next level. Scientists are very passionate about their work and are will to do it often times for very little money. But they stand to gain huge payoffs for a significant contribution to society. I don't know what could be more honorable.
But why does all of this matter, because most computer science majors are not scientists. They are programmers and often times just support people. They are trying to learn something to build a career on. A job in middle America that pays 125K/yr so they can take care of their family, have a nice lifestyle, better computer equipment than their friends and fancy cars to make up for the void of not living out their dreams. But 125K is a tough job to get and a tough job to have.
As far as I know very few universities offer serious software engineering degrees. Most programmers would probably not even major in software engineering simply because they don't understand it is the ticket to their goal. Computer science simply has not given the majority of programmers the necessary tools to make it in the computer industry.
Damien Hogan dhogan@direct-alliance.com 07-19-2005
Comments are important. However there are different types of comments each with varying degrees of priority. Comments are primarily code documentation. Code generally starts with some sort of design and design documents are the first stage of code documentation.
Designs don't have to be monolithic war and peace style documents, rather very high level documents describing the purpose of the code. This generally gives future maintainers of developers an idea of the effect changing the code will have on an application.
Class Documentation / API Documentation / Java Docs / Perl Docs / .Net XML Docs are in my opinion are the most important forms of code documentation. I very much enjoy reading articles about programming concepts and designs. But when I am coding, it is the API documentation that I spend most of the time reading. My favorite languages are those which provide a large library of useful classes that I can reuse. perl, php and Java have large online communities that produce reusable library. This has two effects.
Writing such small reusable libraries generally the documentation will be very good. Each reusable library has documentation that allows other programmers to figure out how to use them. This means people writing these libraries are not only good at writing reusable code. They are also good at instructing others about how to use such code. Over time they become experts at documentation and serve as role models for others developer. .Net is an example of a large development group accepting these practices and now trying to embrace such strategies. But there is a much more interesting aspect to this.
Developers using these libraries become very good at using libraries. As programmers become more experienced, they progressively become more adept at finding reusable code and being able to make it part of a consistent unified solution. Developers who are practicing these techniques are becoming very good at designing and documenting reusable code. Having this community of code exposes developers to an enormous amount of high quality well documented code. This not only allows them to be more efficient developers, but teaches them to be very efficient designers. These are the people who become the respected technical leaders and in the optimistic case your boss or the senior programmers on the projects for your work. Perhaps you are one of those programmers and other a benefiting from your use of such tactics.
The least import type of code comments are the one or two lines before the while loop. These types of comments document the code at a micro level. At this level you rarely need a lot of comments. In most cases a competent developer requires the ability to decompose the code and this level without a lot of comments. This type of comment is never the less on the forefront of most discussion about code comments. Less experienced developers general can figure out the code is difficult to maintain but may not know exactly why. Not having the experience to point at exactly what makes the code difficult to maintain they assume it lacks sufficient documentation. This argument seems almost immediately logical. Unfortunately there is a flaw in this logic.
Just because code is difficult to maintain or enhance does not indicate poor documentation. I have maintained lots of well documented code that required hundreds of hours of modification to fix simple bugs or implement small changes. Several years ago I was asked by my company to help when a new application was released to our clients. This code met the acceptable requirements for code documentation. Each file had a header with modification history including date and developer information. Comments we also placed liberally throughout the code. This projected resulted in a single release and is currently being rewritten from the ground up. When I was asked to assist with the analysis the code documentation helped us quickly conclude the application would not be a viable replac