developer.* Blogs - page - Comments

There's no such thing as something for nothing

Edward G Nilges — Sun, 21 Jan 2007 01:52:48 -0800

See my blog entry with this title, Mr. Toshi.

Do they have to hold true to what is in an offer letter?

Toshi — Thu, 18 Jan 2007 06:07:20 -0800

In my offer letter almost 3 yrs ago it was written that I would get a $300 a month car allowance, no mileage documented. About a year later the Board decided that no one would get a flat rate but rather .40 a mile. In the time since my job descrption has changed drasitically and I no longer dirve much for work so my mileage check are an average of $80. My question is are they legally bound since it is writing to pay me the $300 still? That was a large amount of money and a reason I accepted the position and now I go without it. Do I have any claim to it?
Thank you

Gratitude

Edward G Nilges — Mon, 25 Dec 2006 22:43:55 -0800

See my blog "Being a Dung Beetle Considered Harmful"

Higher or lower

paper shredders — Wed, 06 Dec 2006 23:36:03 -0800

As computer power increases, level of abstraction is raised, allowing the programmer to "design" at a different level, while the design decisions that used to have to be made at a lower level.

Great article!

Ferdy — Mon, 06 Nov 2006 15:54:50 -0800

Hi Mario,

I have spent more than 15 years designing and developing in-house case tools for our legacy systems (more than 1.000 developers). I have implemented almost all of the â€œTraditional CASE toolsâ€ features that you described in your article, and they have proved that they are necessary to archive a very productive development environment.

Now, we are focusing our efforts on distributed systems, and specifically, in OO environments. We have a current discussion about which is the best strategy towards our toolset in these environments. On one side, there is the opinion that we must use OO COTS tools; and on the other side, that we must developed our own tools following the guidelines of the traditional case tools. The absence of some of the features that you stated is inclining the balance towards the second option (the traditional one). Some features, as the central repository relying on databases, are essentials in environments focused in the reusability of the artifacts, and with OO COTS tools you canâ€™t implement them, with or without â€œframeworksâ€. They seem designed for individual developers or small teams and not for a big enterprise.

Congratulations for the article, I have enjoyed reading it.

Professionalism evolves

Carl Gundel — Tue, 24 Oct 2006 14:46:37 -0700

Thanks for a great article! I also started programming as hobby as a child, and knew very quickly that I wanted to be a programmer by profession. That was 27 years ago now. :-) I was very fortunate when I was 15 years old to meet a businessman who trusted me enough to work with me writing business software. This was a great experience for me, and I managed to go straight to work writing software out of high school.

One thing I have noticed is that over time people expect more and more out of professional programmers. The level of richness that people expect from software increases over time, and the amount of knowledge required to attain the minimum expected level of utility grows year after year. In addition to objects programmers must now understand agile methodology, unit testing, source control systems, UML, etc.

Young hobbyists can still program to satisfy themselves of course, but the languages are heavier and less nimble. Ah, I can remember when... ;-)

Professional Programmer Requirements

Daniel Read — Thu, 19 Oct 2006 05:06:20 -0700

Natty,

Your question is a difficult one to answer, because there are no official requirements for becoming a "professional programmer" in the same way that there are for doctors and lawyers and engineers. There is not any certification or standardized curriculum. The way it works generally (at least where I live, in the U.S.) is that you acquire the skills or knowledge any way you can, and then try to convince people to give you a job.

Your ability to get a job is based on how you measure up against other people who are competing for the same job, and also on how much money you are willing to work for. The most desirable and most specialized jobs have the most competition and the highest pay, and the least desirable jobs have the least competition and the lowest pay. Sarah's article (and her web site) is basically about the "informal" journey of becoming a professional programmer, as opposed to a more "formal" or "traditional" path of going to school, getting a degree, and get a job in the software field after college.

A book you might find interesting is After the Gold Rush, by Steve McConnell. Another good resource is the SWEBOK project, which stands for Software Engineering Body of Knowledge. Also, an article I wrote a few years ago called "Making the Cut" addresses some issues related to your question.

Hope that helps,
Dan

please make every thing clear.

Natty — Thu, 19 Oct 2006 00:05:24 -0700

I don't have any comment but i am reading your comments. so, please tell me what the requirements to be a professional programmer. Guys, sorry not sending you a comment rather a question.

First Software Creativity Story

Daniel Read — Fri, 22 Sep 2006 09:32:55 -0700

We received our first entry for the Software Creativity Search contest, from Ben in San Francisco, California. Ben's story describes exactly why we're so excited about the publication of Software Creativity 2.0. Read the story on the new page we've set up for the Software Creativity Search contest.

Thanks for reading,
Dan

My personal experience is

Guest — Fri, 01 Sep 2006 08:03:04 -0700

My personal experience is similar or even simpler.

The key factors are:

1. The problem solving environment

- Hej, Tony I have problems with the Tixxxx certificate.
- OK, sit down I will see if I can help.

2. Quick decision process at the company.

- Hej boss, it seems that we need another Test server for this Fixxxx project. Here are the specifications.
- OK, I talk to the big boss that you come in to the management meeting this afternoon to inform them about the problem. By tomorrow I will tell you if we get the money for that. If not we will find out some solution.

That is it. Deadline helps. But those detailed schedules, timesheets, task lists, weekly reports? According to my several years of experience, they do not help at all. They are just constant headache for those guys who want to deliver product. They are just milestones toward to an environment, where tasks are just thrown among departments, and nobody wants to make decisions.

Deadlines and requirements

chrishmorris — Sun, 27 Aug 2006 23:10:31 -0700

Yes PM, I had the same question. I'm also amused by projects which have no written requirements, and still manage to deliver late.

Some projects have a natural deadline, e.g. a tax calculator must be ready for the end of the financial year. I have never worked on one like that. When I've been given a "deadline", it has been a stretch goal, not based on a well-founded estimate of effort.

Usually the true situation behind a "deadline" is that the requirements are fixed, and the project will in fact continue until they are complete. And the developers usually know this.

Some projects have a time box: we'll deliver as much as we can, to the appropriate quality standard, by the end date, then we'll move on.

With incremental delivery, the payoff for each increment is likely to decrease. The agile ideal is that at every iteration, an assessment is made about whether there is a business justification for continuing development. But I don't know how you write a contract that gives a decent level of security of employment in an environment like that.

The worst case is that end date, resources, and scope are decided in advance, without the participation of the developers. Then failure to meet one of the goals is more or less guaranteed.

If this happens, it may not only be the fault of management. It may be their experience that the developers cannot make useful estimates of effort. I suspect that the result in the report reflects this sort of environment.

No Schedule = Less Pressure = Fewer Compromises

Daniel Read — Fri, 18 Aug 2006 06:22:14 -0700

:-) What I took that to mean was the success was defined as the delivery of the desired functionality, but that the project was not burdened (my word) with a schedule. In other words, the lack of a schedule (which I think of implicitly as an imposed schedule), contributed to the project's success. If you take away time pressures, perhaps you take away pressure.

It also occurs to me that the definition of "schedule" used by the researcher could be important to this discusson. Is schedule in this usage synomous with "deadline," or does it mean "a time-oriented plan with a task breakdown and milestones in a spreadsheet or project management software"?

Dan

Most projects that had no schedule

PM — Fri, 18 Aug 2006 01:33:46 -0700

The article stated this as the first surprise:
"Most projects that had no schedule were successful"
I was just wondering: When do you call a project without schedule a failure?

Nice review, maybe its time for the second edition

Guest — Sun, 30 Jul 2006 00:24:35 -0700

Hi,
I saw that you mentioned that industry lacks updated version od Code Complete, but now, here it is. Published, with added OOP.
I don't know if it is ok to post it here, but you can check out my
review of Code Complete.
Maybe somebody will find it useful to read, before buying the book.

Excellent Point, Chris

Andy Tegethoff — Fri, 28 Jul 2006 06:33:28 -0700

It's this: even in iterative development, there is a lot to be gained from writing the requirements down. The final requirements document will be ready only shortly before the final delivery of software, but in my opinion it's still very useful.

I feel very similarly -- that you only know the requirements once the product moves into production. Requirements documents should be the most "living" of any development artifacts. They are most closely related to user documentation/help -- they have to change through the maintenance life of the code.