I wonder how many programmers actually write applications? If it's just "apps", you know those really stupid programs on "smart" phones that are URLs wrapped inside of XML and given a nice icon, then a very small percentage of programmers actually do that, probably more than we need. If it's all applications for a computer/phone/tablet then I still think it might not necessarily be the majority of developers who do this. I think most devs are doing infrastructure work or support; like IT, operating systems, run time environments, networking, frameworks, toolkits, integration and professional services, bug fixing, etc, Sure the applications need all this but to say that most people will need to do applications in the future is just a bizarre idea probably thought up by someone who doesn't really know programming.
We should treat it like every other science or academic topic. Yes, everyone should know a little bit about everything as part of a good education, but we don't assume everyone is going to grow up to be a scientist.
I got a job one, not a good job mind you, but after a few weeks my boss told me that he was surprised that I actually knew what I had put on my resume. He had assumed that everyone inflated the resume and and was bullshitting during the interview and thought I was just one of the better bullshitters.
(although I did sort of bullshit, he asked about OpenView and I mistakenly thought he was talking about OpenWindows, aka SunView, and I explained how I knew all about it:-)
One sort of question that some of my coworkers ask is to have the interviewee describe the fundamental structure of their last product they worked on. Without disclosing company secrets of course. Ie, what does the system do, what are the blocks in the system, how does the data flow, or whatever. Open ended question.
It is surprising how many people can work for a company for five years and be unable to describe what it is they worked on. Are they just bad communicators or didn't interact with their team, were they only working inside their cubicle and never stepping out of it, did they fall asleep during meetings, was the company highly partititioned, or what?
Don't forget the related item, that if something is mentioned in a job listing then it's a good idea to brush up on it before going to the interview. If the company makes wickets then it's a good idea to learn what wickets are. Part of the interview is convincing the company that they want hire you instead of all the other bozos who want the job.
For someone *senior*, it would be nice if they understood some of the fundamental concepts in perhaps eight of those dozen other specialities. The question did not ask about advanced concepts in encryption, but something that's described in a paragraph on wikipedia along with handy pictures. A beginner question in other words (though asking how to encrypt and send a file is not really beginner, that requires more knowledge about actual current products). Similarly, asking a basic networking question should be fair game as well, as in compare and contrast UDP vs TCP.
Designers need to understand security. Not just code security but the security architecture. Ie, how to you protect data on your network protocol, how to you manage key exchange, how can you keep customer data secure from prying eyes, how can you prove to the customers that you know what you're doing. Designers need to meet with the security architect and understand what is being said.
Sure, if someone wants to remain a junior developer forever then they can stick to that.
It's a subject the vast majority of senior developers *should* know about. You need to know something about it to design web sites, routers, embedded systems, even games. You don't need to know the details of course but the concepts are fundamental. Ie, what are public/private keys, why are there two keys, which key gets to be distributed, etc. Stuff that you can put up on a white board easily. These aren't advanced security concepts.
Of course even though it should be known, it commonly is not, which is why there are so many security problems out there. Security is being treated as an after thought, added on after the basic functionality is done and the ship date is carved in stone. My current company has expanded into two buildings previously occupied by a company that didn't bother with security and as a result imploded.
True, if a candidate does not know about public/private key encryption then it's pretty safe to assume they know almost nothing about security, as it's the basis for most everything security related in the last several decades. Time to move on to the next topic at that point.
The programers working on such a system must know how the various components work. Someone who programs only within a tight bubble without seeing the big picture is called a junior programmer. The programmer doing the file system should know that there will need to be a distinction between storage of private keys versus public keys. The system designer needs to plan for the security component starting from day one, since we already have far too many systems where security is tacked on at the end as an afterthought. The network layer designer has to be involved with the security designer. The application designer needs to know about security. Even to test or debug some systems the developer needs to understand some basics of security. If a developer thinks that security is just about calling the right API at the right time they're likely to be a liability.
Note the tendency on Slashdot to have questions like "how can I be a programmer without going to school?". A generation of intentionally ignorant developers could arise from this. Getting breadth of knowledge is vital as a programmer, even as a non-programmer. But so many people think that they can find a short cut, or focus on a very narrow range of topics, and then miss out learning important stuff. I do agree that people can be self taught, but that often leads to people who only learn the interesting stuff because people who are self taught don't often go out of their way to learn boring stuff.
Certainly we don't need developers who know *everything*. But we need developers that know something other than freshman level programming. If I was doing the same thing as my first entry level job for my entire life I'd go crazy, and yet I think some people are destined to do just that.
The problem is that your personal choice affects the health and welfare of other people. People do not live alone on their private planets. If you dump toxic waste in your back yard that may be your own personal decision but it is absolutely catastrophic to the neighbors. Failing to vaccinate is similar though with a lesser chance of tragedy.
There have been cases of parents going to jail after a child has died, not for failing to vaccinate but for other cases where the parent relies on faith healing or alternative medicines.
Jenny McCarthy is afflicted with her own disease, that of believing that mothers instinctively know what's best for their children at all times. A malady that seems to be very common.
I think a prerequisite to being in politics is to assume you know better than anyone else how to run things. ("why is everyone in the country an idiot except for me?")
A "break" is technically a goto. Some people refuse to even allow a break in anything other than a switch statement.
But if you get past that then this style is very appropriate to use. For some reason I see this being used very rarely even though the concept is straight forward.
Sometimes you can't afford that. Ie, I'm working on a chip with extremely limited memory. We run out long before the project is working well enough for even a demo, so we must start optimizing for space before it's correct or understandable. There are other cases I've had in the past where a real time deadline can't be met without doing some optimization (which generally means stop coding the naive way).
If you *know* you're in the inner loop then why postpone writing code that is more efficient than the naive method since you *know* the optimization will be needed? Too often once the code is finished for "correctness and understandability" then the project ships and no time is given for "optimizing". Which can sometimes mean that a few months later management is in a panic because customers are complaining about how slow everything is.
"Don't prematurely optimize" is another one of those proverbs that people worship without thinking about it. Not optimizing prematurely means doing a linear search through an array instead of using a built in function or data structure that is more efficient. Yes, in some places the linear search is appropriate as the code is not called often. But using a mapping data structure can speed things up and even use less coding and design time. I have run across a case where there were three linear searches nested within each other and for the end user the delay was noticeable and annoying, and caught the attention of the system administrator for excessive use of some system calls. The inner most loop in that case was something that the author would have known was a very critical function and should have spent minimal time thinking about the design instead of plopping in a naive solution.
I think the indentation is evidence that it's very difficult to make code look good in Slashdot. Especially a quick off-the-cuff code example meant to illustrate a point.
Not even exceptions, I think that the vast majority of these gotos are a jump to the cleanup code. So having code that automatically executes on function return, like with C++ destructors on auto variables, would solve the problem.
The snag with exceptions is that with many embedded systems they may take too much overhead.
I definitely "avoid" the goto myself, and I think the branch to end of function style gets used far too much at work. However I have run across some cases where it's cleanest way to handle things. Ie, five resources are acquired with computation occuring between each acquisition, any of which could fail and need cleaning up. To split that into nested functions is clumsy, or to add an extra "abort" variable to skip all subsequent code. In C++ it's trivial to handle as you can return or throw an exception and let the destructor clean up things.
There are ways to avoid this in some languages. Ie, in C++ you can handle the cleanup on return in a nice way, releasing semaphores and memory automatically, using exceptions where allowed (sometimes can't use these in embedded systems). In C no such luck. The lower the level of the language the more likely it is to sometimes want to use low level constructs.
What if I actually am an expert? Am I still bound by your superstitions about goto? It's one thing to tell a student or beginner to avoid goto, but another thing to place an absolute prohibition on them.
The original goto-considered-harmful paper was written at a time when structured programming was extremely rare, spaghetti code was common, and the flowchart was a common design method. We're decades past that time though and the general programming style everywhere is to be highly structured. So the same repulsion about using goto is no longer necessary, we know enough to not use it at a whim but should be allowed to use it when it is indeed appropriate in languages which do not have the necessary structured constructs to avoid it.
Goto is a very useful construct. But because of your item #1 that you list, most people have been trained that the worst thing you can ever possibly do when programming is to use a goto. It is a taboo to a lot of people, essentially a superstition. They're not considering the pros and cons in a particular use case and instead reject it utterly without thinking.
Too many times the only way to refactor the code to get rid of gotos is to add extra state variables or extra leaf functions.
Granted some languages make it even easier to avoid goto, such as C++ with destructors doing the cleanup with automatic variables. But in C you don't have that, so often it is much cleaner and the code is easier to understand to just goto the end where clean up is done. Restructuring the code to avoid that will very often make things harder to understand.
Now the worst of course I think is the programmer who avoids goto at all costs who also insists on only a single return from a function. I've seen some bizarre code written that way.
Slashdot Mirror
I wonder how many programmers actually write applications? If it's just "apps", you know those really stupid programs on "smart" phones that are URLs wrapped inside of XML and given a nice icon, then a very small percentage of programmers actually do that, probably more than we need. If it's all applications for a computer/phone/tablet then I still think it might not necessarily be the majority of developers who do this. I think most devs are doing infrastructure work or support; like IT, operating systems, run time environments, networking, frameworks, toolkits, integration and professional services, bug fixing, etc, Sure the applications need all this but to say that most people will need to do applications in the future is just a bizarre idea probably thought up by someone who doesn't really know programming.
We should treat it like every other science or academic topic. Yes, everyone should know a little bit about everything as part of a good education, but we don't assume everyone is going to grow up to be a scientist.
The follow on question is how did you fight the monster?
One up, one down, and one to polish.
I got a job one, not a good job mind you, but after a few weeks my boss told me that he was surprised that I actually knew what I had put on my resume. He had assumed that everyone inflated the resume and and was bullshitting during the interview and thought I was just one of the better bullshitters.
(although I did sort of bullshit, he asked about OpenView and I mistakenly thought he was talking about OpenWindows, aka SunView, and I explained how I knew all about it :-)
One sort of question that some of my coworkers ask is to have the interviewee describe the fundamental structure of their last product they worked on. Without disclosing company secrets of course. Ie, what does the system do, what are the blocks in the system, how does the data flow, or whatever. Open ended question.
It is surprising how many people can work for a company for five years and be unable to describe what it is they worked on. Are they just bad communicators or didn't interact with their team, were they only working inside their cubicle and never stepping out of it, did they fall asleep during meetings, was the company highly partititioned, or what?
Don't forget the related item, that if something is mentioned in a job listing then it's a good idea to brush up on it before going to the interview. If the company makes wickets then it's a good idea to learn what wickets are. Part of the interview is convincing the company that they want hire you instead of all the other bozos who want the job.
For someone *senior*, it would be nice if they understood some of the fundamental concepts in perhaps eight of those dozen other specialities. The question did not ask about advanced concepts in encryption, but something that's described in a paragraph on wikipedia along with handy pictures. A beginner question in other words (though asking how to encrypt and send a file is not really beginner, that requires more knowledge about actual current products). Similarly, asking a basic networking question should be fair game as well, as in compare and contrast UDP vs TCP.
Designers need to understand security. Not just code security but the security architecture. Ie, how to you protect data on your network protocol, how to you manage key exchange, how can you keep customer data secure from prying eyes, how can you prove to the customers that you know what you're doing. Designers need to meet with the security architect and understand what is being said.
Sure, if someone wants to remain a junior developer forever then they can stick to that.
It's a subject the vast majority of senior developers *should* know about. You need to know something about it to design web sites, routers, embedded systems, even games. You don't need to know the details of course but the concepts are fundamental. Ie, what are public/private keys, why are there two keys, which key gets to be distributed, etc. Stuff that you can put up on a white board easily. These aren't advanced security concepts.
Of course even though it should be known, it commonly is not, which is why there are so many security problems out there. Security is being treated as an after thought, added on after the basic functionality is done and the ship date is carved in stone. My current company has expanded into two buildings previously occupied by a company that didn't bother with security and as a result imploded.
True, if a candidate does not know about public/private key encryption then it's pretty safe to assume they know almost nothing about security, as it's the basis for most everything security related in the last several decades. Time to move on to the next topic at that point.
The programers working on such a system must know how the various components work. Someone who programs only within a tight bubble without seeing the big picture is called a junior programmer. The programmer doing the file system should know that there will need to be a distinction between storage of private keys versus public keys. The system designer needs to plan for the security component starting from day one, since we already have far too many systems where security is tacked on at the end as an afterthought. The network layer designer has to be involved with the security designer. The application designer needs to know about security. Even to test or debug some systems the developer needs to understand some basics of security. If a developer thinks that security is just about calling the right API at the right time they're likely to be a liability.
Note the tendency on Slashdot to have questions like "how can I be a programmer without going to school?". A generation of intentionally ignorant developers could arise from this. Getting breadth of knowledge is vital as a programmer, even as a non-programmer. But so many people think that they can find a short cut, or focus on a very narrow range of topics, and then miss out learning important stuff. I do agree that people can be self taught, but that often leads to people who only learn the interesting stuff because people who are self taught don't often go out of their way to learn boring stuff.
Certainly we don't need developers who know *everything*. But we need developers that know something other than freshman level programming. If I was doing the same thing as my first entry level job for my entire life I'd go crazy, and yet I think some people are destined to do just that.
The problem is that your personal choice affects the health and welfare of other people. People do not live alone on their private planets. If you dump toxic waste in your back yard that may be your own personal decision but it is absolutely catastrophic to the neighbors. Failing to vaccinate is similar though with a lesser chance of tragedy.
There have been cases of parents going to jail after a child has died, not for failing to vaccinate but for other cases where the parent relies on faith healing or alternative medicines.
Jenny McCarthy is afflicted with her own disease, that of believing that mothers instinctively know what's best for their children at all times. A malady that seems to be very common.
I think a prerequisite to being in politics is to assume you know better than anyone else how to run things. ("why is everyone in the country an idiot except for me?")
A "break" is technically a goto. Some people refuse to even allow a break in anything other than a switch statement.
But if you get past that then this style is very appropriate to use. For some reason I see this being used very rarely even though the concept is straight forward.
Sometimes you can't afford that. Ie, I'm working on a chip with extremely limited memory. We run out long before the project is working well enough for even a demo, so we must start optimizing for space before it's correct or understandable. There are other cases I've had in the past where a real time deadline can't be met without doing some optimization (which generally means stop coding the naive way).
If you *know* you're in the inner loop then why postpone writing code that is more efficient than the naive method since you *know* the optimization will be needed? Too often once the code is finished for "correctness and understandability" then the project ships and no time is given for "optimizing". Which can sometimes mean that a few months later management is in a panic because customers are complaining about how slow everything is.
"Don't prematurely optimize" is another one of those proverbs that people worship without thinking about it. Not optimizing prematurely means doing a linear search through an array instead of using a built in function or data structure that is more efficient. Yes, in some places the linear search is appropriate as the code is not called often. But using a mapping data structure can speed things up and even use less coding and design time. I have run across a case where there were three linear searches nested within each other and for the end user the delay was noticeable and annoying, and caught the attention of the system administrator for excessive use of some system calls. The inner most loop in that case was something that the author would have known was a very critical function and should have spent minimal time thinking about the design instead of plopping in a naive solution.
I think the indentation is evidence that it's very difficult to make code look good in Slashdot. Especially a quick off-the-cuff code example meant to illustrate a point.
Not even exceptions, I think that the vast majority of these gotos are a jump to the cleanup code. So having code that automatically executes on function return, like with C++ destructors on auto variables, would solve the problem.
The snag with exceptions is that with many embedded systems they may take too much overhead.
I definitely "avoid" the goto myself, and I think the branch to end of function style gets used far too much at work. However I have run across some cases where it's cleanest way to handle things. Ie, five resources are acquired with computation occuring between each acquisition, any of which could fail and need cleaning up. To split that into nested functions is clumsy, or to add an extra "abort" variable to skip all subsequent code. In C++ it's trivial to handle as you can return or throw an exception and let the destructor clean up things.
There are ways to avoid this in some languages. Ie, in C++ you can handle the cleanup on return in a nice way, releasing semaphores and memory automatically, using exceptions where allowed (sometimes can't use these in embedded systems). In C no such luck. The lower the level of the language the more likely it is to sometimes want to use low level constructs.
What if I actually am an expert? Am I still bound by your superstitions about goto?
It's one thing to tell a student or beginner to avoid goto, but another thing to place an absolute prohibition on them.
The original goto-considered-harmful paper was written at a time when structured programming was extremely rare, spaghetti code was common, and the flowchart was a common design method. We're decades past that time though and the general programming style everywhere is to be highly structured. So the same repulsion about using goto is no longer necessary, we know enough to not use it at a whim but should be allowed to use it when it is indeed appropriate in languages which do not have the necessary structured constructs to avoid it.
I'd quit before then. Sheesh, evaluate the code on its merits instead of dogma.
Goto is a very useful construct. But because of your item #1 that you list, most people have been trained that the worst thing you can ever possibly do when programming is to use a goto. It is a taboo to a lot of people, essentially a superstition. They're not considering the pros and cons in a particular use case and instead reject it utterly without thinking.
Too many times the only way to refactor the code to get rid of gotos is to add extra state variables or extra leaf functions.
Granted some languages make it even easier to avoid goto, such as C++ with destructors doing the cleanup with automatic variables. But in C you don't have that, so often it is much cleaner and the code is easier to understand to just goto the end where clean up is done. Restructuring the code to avoid that will very often make things harder to understand.
Now the worst of course I think is the programmer who avoids goto at all costs who also insists on only a single return from a function. I've seen some bizarre code written that way.
I've spent 10 years in CS, and never heard of aspect-oriented programming until it appeared in a corporate setting.