Picking up from the last post, Jeff Atwood at Coding Horror referenced a Joel Spolsky post about the ideal programmer education where Joel was suggesting a Bachelor of Fine Arts in Programming.
I had a WTF moment on that.
He advocates a 1/3 liberal arts, 2/3s software development curriculum. Perhaps it's just my engineering education, but I found that many of the engineering students I learned with were quite well rounded, while the LA students tended to be missing the hard science side of things – so I'd naturally suggest an emphasis on the engineering side would be better, since we engineering geeks often have enough side interests to round us out.
But more to the point, I can't see how anyone in the business can think that programming is a Fine Art. At best it might be a Practical Art – Fine Arts are things like dance, music, painting. A friend of mine is an artist, but since he was planning to work in advertising, his degree was not a Fine Arts degree. And moreso, given the amount of math that we do make use of in CS/programming, I'd submit that it's at least a craft, and closer to a young engineering discipline. It's still young enough that the edges are fuzzy, and we need a good deal of creativity to solve the issues we face.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, February 18, 2008
Becoming a Programmer, part 1
A few weeks ago, I ran across a post at Coding Horror where Jeff goes into what he thinks is a better way to teach Computer Science to undergrads. He describes how everything should be done according to best practices – all code in source control, everything needs an installer, every program will have bug reports – and the developer has to fix the bugs. He even states that it would be excruciating.
So while there is plenty of room for improvement in the education of a software developer, it shouldn't be like dropping someone onto a speeding motorcycle; it should be like learning to ride a bike - you spend some time with training wheels first.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I think that would be like training an airline pilot to fly by making them take the stick of an F-22 in the middle of a dogfight. There is a certain level of proficiency that is needed before you can progress, and if a student hasn't reached this level, all the trial by fire will do is char them. You need to get them to the point where they are not concerned about how to write code before you make them work in the framework that code exists in. A personal anecdote – I had to learn how to develop code in C under UNIX at the start of my first compiler course; but I already knew how to program in other languages, so C was just new syntax, and UNIX was not too much of a hurdle.
Now, once a student has taken a couple of programming courses, a series of courses that do enforce real-world constraints would be very desirable. All courses after the introductory set could require source control, and some could deal with portions of the real-world, like versioning – start with a simple 2-week project, and once that's done, start adding new features, and some back-porting. Another could deal with code repair – everyone gets a copy of a program that has bugs, and they need to fix them.
Another issue I have with Jeff's post is that it assumes all software is PC-based, web-centric, standalone applications. Developers working on a single server in a large application suite that runs under UNIX, for example, might not need to worry about deployment, because that is a solved issue for that system – their new version of the server will be packaged by the existing tools, and the upgrade issues are part of the DBA's work.
So while there is plenty of room for improvement in the education of a software developer, it shouldn't be like dropping someone onto a speeding motorcycle; it should be like learning to ride a bike - you spend some time with training wheels first.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, January 09, 2008
How the Sausage Gets Made
I saw one of Jeff Atwood's Coding Horror posts where he states that nobody cares if the code you write is ugly code or not, as long as it works. While I have some basic agreement, I have a big qualifier - if they are a customer and do not expect to get bug fixes from you, they don't care.
However, if they expect you to fix the bugs they find, or are your manager, they do, or at least should care. Ugly code is harder to maintain, harder to improve, and sometimes harder to find developers to work on.
Jeff has a point, that trying to make code pretty without a business purpose is programmer vanity, but there is a cost to using working, but bad code. This article about technical debt is a good discussion of the tradeoffs.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
However, if they expect you to fix the bugs they find, or are your manager, they do, or at least should care. Ugly code is harder to maintain, harder to improve, and sometimes harder to find developers to work on.
Jeff has a point, that trying to make code pretty without a business purpose is programmer vanity, but there is a cost to using working, but bad code. This article about technical debt is a good discussion of the tradeoffs.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, December 06, 2007
Pilot Error
aThe Job had an interesting filed issue, one where a running process had its RPC binding hijacked by a manual invocation of the same program. This had the puzzling effect of blocking new connections, while leaving existing connections intact.
So the Ninja Lesson from that is twofold:
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So the Ninja Lesson from that is twofold:
- servers must be controlled so that an accidental start will not clobber an already running process
- this means making all your '1-of' initializations must be explicit, and after the check for an already running copy
- you need a check for already running copy
- you need to make it difficult for your servers to be accidentally invoked
- make a user for general observation/maintenance not have execute permission for your servers
- remove the server directory from the path
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, November 21, 2007
Put up guardrails!
Stop programming like the architects of Star Wars - the same idiots who failed to put up guardrails around bottomless pits.
From the "Just Last Week" files:
I found out that a very bright developer wrote code made the bad mistake of thinking that he would always be the only developer in charge of his code. He wrote multithreaded code that did not protect a very useful, method-laden collection of data from simultaneous access by 2 or more threads. His rationale was that he would, by convention, only access the dataspace from the main thread. Then he had the gall to get transferred away from the development group, and The Ninja got his code. And promptly found there were several cases of a secondary thread accessing the dataspace, the unprotected dataspace, at the same time as the main thread was modifying it. The predictable result was a program crash.
You cannot ever expect the developers who follow you to know or remember all the little rules you've set up for your own little code kingdom. You ignore the Best Practices at your own peril. If you are working in a multi-threaded process, you must assume that all threads may access a global data structure, and if it gets modified, those accessing the data will crash. Assuming that the next guy will not tromp on your daisies is foolish.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
From the "Just Last Week" files:
I found out that a very bright developer wrote code made the bad mistake of thinking that he would always be the only developer in charge of his code. He wrote multithreaded code that did not protect a very useful, method-laden collection of data from simultaneous access by 2 or more threads. His rationale was that he would, by convention, only access the dataspace from the main thread. Then he had the gall to get transferred away from the development group, and The Ninja got his code. And promptly found there were several cases of a secondary thread accessing the dataspace, the unprotected dataspace, at the same time as the main thread was modifying it. The predictable result was a program crash.
You cannot ever expect the developers who follow you to know or remember all the little rules you've set up for your own little code kingdom. You ignore the Best Practices at your own peril. If you are working in a multi-threaded process, you must assume that all threads may access a global data structure, and if it gets modified, those accessing the data will crash. Assuming that the next guy will not tromp on your daisies is foolish.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Too Much Information
I'm all for the freedom of information, among individuals. In the corporate world, there are sometimes
good reasons not to tell someone part of the story.
Case in point (with serial numbers filed off) - a discussion last week touched upon an old release, where there was a big improvement in performance, brought about when a developer found an inefficiency in transaction processing, removed it. In the process of this release, upper management was pressing for a rationale, and someone offered a detailed explanation of the issue, using the names of the various classes in the code. Because some of the class names were chosen for their purpose in the code, they had a rather ironic connotation in the situation. This led to essentially a disparaging attitude towards the development team in upper management, which is never good, because then the expertise of the developers in their field is undermined.
The Ninja Solution(tm) is to implement a Gaussian blur for the information when talking to upper management (anyone higher up than your immediate superior). Never mention class names to them. Never describe the algorithms by the code names - blur out that level of detail. This prevents the bosses from finding humor in their misunderstandings of the code flows.
Note that this is not a license to lie to them - just to tweak the level of detail you use to report upwards (and sideways - program managers don't need to know class names either.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
good reasons not to tell someone part of the story.
Case in point (with serial numbers filed off) - a discussion last week touched upon an old release, where there was a big improvement in performance, brought about when a developer found an inefficiency in transaction processing, removed it. In the process of this release, upper management was pressing for a rationale, and someone offered a detailed explanation of the issue, using the names of the various classes in the code. Because some of the class names were chosen for their purpose in the code, they had a rather ironic connotation in the situation. This led to essentially a disparaging attitude towards the development team in upper management, which is never good, because then the expertise of the developers in their field is undermined.
The Ninja Solution(tm) is to implement a Gaussian blur for the information when talking to upper management (anyone higher up than your immediate superior). Never mention class names to them. Never describe the algorithms by the code names - blur out that level of detail. This prevents the bosses from finding humor in their misunderstandings of the code flows.
Note that this is not a license to lie to them - just to tweak the level of detail you use to report upwards (and sideways - program managers don't need to know class names either.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, October 07, 2007
A Note To Managers
A note to managers:
When your staff tells you that they cannot under any circumstances do a particular thing, LISTEN TO THEM! Do not keep asking them to do something that they have strongly stated they will not or cannot do. It will only serve to make them feel that you do not care about their issues at all. It will undermine morale, demotivate them, and make them less likely to expend extra effort to further the job, since it will felt as excessive sacrifice, given that they will be asked to do more and more later on.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
When your staff tells you that they cannot under any circumstances do a particular thing, LISTEN TO THEM! Do not keep asking them to do something that they have strongly stated they will not or cannot do. It will only serve to make them feel that you do not care about their issues at all. It will undermine morale, demotivate them, and make them less likely to expend extra effort to further the job, since it will felt as excessive sacrifice, given that they will be asked to do more and more later on.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)