Slashdot Mirror

Unexpected encounters with dirty code will make it very difficult to make a sane prediction.

Dirty code is defined as ' overly complex or highly coupled.' As a programer you are expected to deliver X number of features by Y date. Unless one of those features is 'simple and loosely coupled code' what does that have to do with predicting anything? For performance you don't predict. Experiments are the only thing you have that work: test and change and re-test and un-change and re-test, endlessly. Anything else is voodoo programming, not to insult the pracitioners of Santaria, Vodou or Hoodoo.

How about predicting the schedule? I recall that Steve McConnell once joked that to get better at estimating we need to get better at estimating. (This may have been someone else.) Greg Wilson showed we can do this in programming, and Computer Science in general. We only have to do scientific experimentation with various methods. We throw away what doesn't work (instead of writing pulpy business books to bilk people out of money.) But you'll still have to run a lot of tests to do that, too.

It is not uncommon to see "quick" refactorings eventually taking several months to complete. In these instances, the damage to the credibility and political capital of the responsible team will range from severe to terminal. If only we had a tool to help us identify and measure this risk.

It is my opinion that any refactoring that cannot be done by an automatic program isn't refactoring. The original definition of refactoring is just 'factoring' or re-organizing the code. It is not a re-writing as in an 'several months' effort.

Misuse of a sexy, trendy name from the 90s does not change this. All re-writing suffers the risk of second-system syndrome and not in the throw-one-away sense of prototyping. Do you have a button to press in your IDE to make the change? Do you have in mind a short sed statement, simple awk program, EMACS macros or a on-hand shell scriptlet to do the transformation? If not then you cannot get away from re-thinking the problem. This will require re-design of the solution and re-implementation of the feature. Each of these carries time risk at least as high as the original work.

What if the problem is overly complex or highly coupled? The code may merely be an expression of this. In this case only a paradigm or perspective change by the customer, developer or user can untangle the problem. The computer cannot help you do anything but automate making a mess if the problem is a mess. Changing perspective is often an unbound-in-time problem for human beings. Good luck with estimating completion dates for that.

In fact, we have many ways of measuring and controlling the degree and depth of coupling and complexity of our code. Software metrics can be used to count the occurrences of specific features in our code. The values of these counts do correlate with code quality.

In fact, Greg Wilson showed in his presentation that almost every metric on the market when analyzed showed no better and usually equal predictive power as simple counts of Lines of Code.

The situation in programming is almost as if more code equals more bugs while less code equals less bugs.

This seems obvious and

Sure. Update your resume and start pounding the pavement (make use of any contacts you might have first, then hit the usual online boards). Or strike out on your own (maybe take a few friends with you, depending on what you signed when you started) and build web apps as a contractor.

Fact remains that your best chance at a pay (and maybe responsibility) increase is to switch employers.

If you're set on staying where you are, the same kinds of things that you would do to make yourself look good on a resume (e.g., enumerate your accomplishments in terms that can be seen to relate to a company's bottom line - not necessarily in a dollars and cents-specific manner, but in way that makes clear what you built or directed and how you took responsibility) can also help you when talking to your manager.

If you're strictly looking for a raise, first do some research about prevailing pay rates (check ads; check GlassDoor) - if you're underpaid, you have an easier case (you can also try talking to friends at work - good friends, as pay tends to be something people don't talk about and management encourages not talking about it for obvious reasons). Either way, you want to present a case that has something for them, too. Saying "I think I deserve a raise" doesn't help much and creates defensiveness. Better to come to an agreement about a goal. Ramit Sethi has some great advice in How to Hack Your Day Job (short article and a couple of videos).

If you're looking for a promotion, and not so much the money, you still want to proceed along the same lines, but first consider whether the company has openings at the level you're looking at. If you want to go from, say, developer to senior developer, that's likely not a problem since the company defines what "senior developer" means, and you can help yourself by examining others at that level and trying to do what they do as well as you can within the constraints of your present position. However, moving to a lead/manager position will require an opening. For any promotion, try to take on more responsibility where you are - volunteer to write requirements documents, coordinate builds, create tools and processes that streamline or automate poor processes. Keep a log of these accomplishments, even if it's just in a text file, so you can present specific reasons when discussing advancement.

A book I'm reading now called Dinosaur Brains (Albert J. Bernstein) has some interesting observations about office politics and psychology and it may be helpful to you. Avoiding "office politics" isn't really an option, but you can participate on your own terms. Seth Godin's books—Lynchpin (on being indispensable), in particular, in your case, and perhaps The Dip—will also be helpful and help you marshal your arguments and perhaps give you a push to move forward or move on to somewhere that can better use your talents.

You make some good points, but, I think, miss a few things. Yes, an executive may be a low-stress job at some times - but it's a heck of a lot of work to get there for most (look at Jack Welch's biography, for instance - interestingly, he actually did have an earned Ph.D and considered teaching). You don't get hired to the top job without having proven yourself first (sometimes, I'm sure, nepotism comes into play, but it does anywhere and one would expect it to be less likely in C-level positions that need approval by the board of directors).

Regarding teachers having college degrees: do "we" expect that, or is it just another artificial barrier to entry thrown up by public school teachers and their unions? There are periodic Slashdot articles about the potential for non-degreed IT workers, and it is generally agreed that it's more difficult to break in than for those with a degree, but certainly doable. You may even say "we expect developers to have college degrees", but it's not a prescribed requirement. Many government jobs, including teaching, don't even let someone without a degree apply.

An MBA isn't necessarily even going to pay for itself, either (see, e.g., The Personal MBA site and arguments), although if lucky one might make some useful personal contacts in b-school. To just learn the material can be done without the paper - the same could be said for a Ph.D, especially in fields where expensive equipment is not required; but people don't expect to hit easy street with a Ph.D as some do with an MBA.

I would also submit that fewer people go into part-time doctoral programs not because of the difficulty of the work (everything I've seen indicates it's more mind-numbing and even demeaning than challenging) but the difficulty of getting accepted. Compared to what I expected, my part-time Master's program was fairly easy, so I took the opportunity to get decent grades (although it really doesn't matter for anything). Now, that doesn't involve original research, sure, but it still seems reasonable that getting accepted - which depends on people recommending you as a researcher - is more difficult than actually completing the degree, especially with a good adviser. And then, indeed, there's the "post-doc treadmill" to face, struggle for tenure, etc., which I think the linked article did a fairly good job of enumerating. Understanding this, we had someone return to our development team from a Ph.D program when I was at Microsoft (I offer this as a single data point only and not evidence of a trend or the like).

With teachers it is both.

My ex was a teacher and I am considering entering the profession. A college degree is still not good enough. No Child Left Behind dictates for a teacher to be highly qualified, he or she must have a degree in the area to teach, plus pass a highly qualified exam, plus then pass a teachers exam to be certified. In the case of non education majors many states do offer emergency teaching credentials where you have to prove your degree, pass a test, and then study for a year to learn teaching methods and then you have a perment teaching credential.

The unions did have a part in that similiar to lawyers with the bar exam, or accountants with the CPA combined with laws. If the teachers union is going to protect bad teachers at least they can implement such a system to weed out non qualified ones in.

You make some good points, but, I think, miss a few things. Yes, an executive may be a low-stress job at some times - but it's a heck of a lot of work to get there for most (look at Jack Welch's biography, for instance - interestingly, he actually did have an earned Ph.D and considered teaching). You don't get hired to the top job without having proven yourself first (sometimes, I'm sure, nepotism comes into play, but it does anywhere and one would expect it to be less likely in C-level positions that need approval by the board of directors).

Regarding teachers having college degrees: do "we" expect that, or is it just another artificial barrier to entry thrown up by public school teachers and their unions? There are periodic Slashdot articles about the potential for non-degreed IT workers, and it is generally agreed that it's more difficult to break in than for those with a degree, but certainly doable. You may even say "we expect developers to have college degrees", but it's not a prescribed requirement. Many government jobs, including teaching, don't even let someone without a degree apply.

An MBA isn't necessarily even going to pay for itself, either (see, e.g., The Personal MBA site and arguments), although if lucky one might make some useful personal contacts in b-school. To just learn the material can be done without the paper - the same could be said for a Ph.D, especially in fields where expensive equipment is not required; but people don't expect to hit easy street with a Ph.D as some do with an MBA.

I would also submit that fewer people go into part-time doctoral programs not because of the difficulty of the work (everything I've seen indicates it's more mind-numbing and even demeaning than challenging) but the difficulty of getting accepted. Compared to what I expected, my part-time Master's program was fairly easy, so I took the opportunity to get decent grades (although it really doesn't matter for anything). Now, that doesn't involve original research, sure, but it still seems reasonable that getting accepted - which depends on people recommending you as a researcher - is more difficult than actually completing the degree, especially with a good adviser. And then, indeed, there's the "post-doc treadmill" to face, struggle for tenure, etc., which I think the linked article did a fairly good job of enumerating. Understanding this, we had someone return to our development team from a Ph.D program when I was at Microsoft (I offer this as a single data point only and not evidence of a trend or the like).

http://personalmba.com/best-business-books/

I have to disagree with much of your post, as you're conflating a number of (yes, related) issues - such as how to live frugally versus how to be a freelance web developer.

More importantly, right off the bat on your first remark, you've told the person that, in all likelihood, they've earned an 'F' because they don't know their market, and that is that. I mean, that line (and most in this post) read as though they were taken straight out of a 'how to' book on business - and not the freelance Web work they're looking at. If the poster wanted that, there are plenty of places to go.

To my mind, the most important adage is "Don't train, do." You can spend a lot of time on the various points suggested - market research, for instance, or cold calling businesses, or making business cards. But there is a core to the business - doing web development. Figure out what the bare minimum is for that, and get going. Every moment wasted on anything else is moments you're not getting paid. Why sit around trying to think of ten good reasons someone shouldn't hire you? And what to say? The best reasons someone won't hire you will come up when they don't, and the best rejoinders will come with practice.

The point is that no one, out of the gate, has really any of this. You can go from zero to a successful business, but you're asking them to plan on plenty - when in all likelihood they should plan on nothing, keep an eye out for why they fail the first ten times, and learn to adapt. That is the learning curve that is needed - not how many business cards they need, or how to see fifty clients a week (which, by the way, good luck - that's ten clients a day, which is highly unlikely even if you can find them). If the person in question wants to be a salesman, then by all means, go that route. If they're going to be a developer, then they need to develop.

To my mind, there are three important pieces that all else are subordinate to:

1) Be capable. Know what you're trying to sell. You may fail to sell it, but that will get you farther than if you sell something you fail to be able to deliver.
2) Have something to show. Suits and business cards are all well and good, but if you cannot demonstrate the product they want, they'll see right through you.
3) Document everything, and review it. People get shafted by not having documentation that proves they did the work. They also lose track of where a project started to fail and why. By documenting (and showing the clients) everything, you not only keep them honest, protect yourself for the future, but you also are able to trace where it is you went wrong, and adapt.

But all of that aside, if you want to do it, you're ready. Ignore anyone who says otherwise. You may fail - but you'll get over that. Not starting is a far worse fate.

Take a look at the books on this site, a good selection for self study

http://personalmba.com/

TAOPM is on the Personal MBA book list.
http://www.personalmba.com/
http://www.amazon.com/exec/obidos/tg/guides/guide- display/-/2T49HSJQJBYI1/
The author meets with people there to discuss concepts in the book. I highly recommend the Personal MBA to anyone looking to further their business management knowledge. I'm working on mine right now.