How to Keep Your Job

An anonymous reader submits: "Dave Thomas of "Pragmmatic Programer" fame presents the first in a series of slides based on presentations about how programmers can maintain job security in this time of increased competition, cost cutting, outsourcing, etc. He makes several excellent points about things many programmer may not think about such as the dangers of over-reliance on one company or sector, the importance of diversity of knowledge, the fact that foreign programmers CAN produce quality code, and the fact that time does NOT necesserily equal value (the Everquest Syndrome) when it comes to software engineering. There is a lecture that goes along with the slides, but a great deal can be learned from the slides alone. Worth the read..."

Comments

CMM?

[sporty]

CMM is a tool for identifying process ability, not code quality. i.e.

Someone at CMM 1 would be totally chaotic. Think waterfall on crack, skipping about back and forth randomly, developers coding on the whim of people.

At CMM5, there's be a strict set of policies (1 or 2, maybe more) that are repeatable, managed and are being optimized.

To say that developers across seas bring about CMM 3 or 4 is saying nothing. CMM isn't about one type of people, much less any people. It's about process a group uses to deliver. If they mean consultant companies across seas have higher CMM, maybe, but I'd think the language barrier would slow things down.

Re:CMM?

[emag]

Right, this always bugged me when we were getting CMM rammed down our throats. Management kept saying how it would improve the quality of our code and make us competitive. Us grunts pointed out that (aside from wasting quite a bit of time in CMM-related presentations), all it would do is codify the existing process, even if flawed. So if we had a process that produced severely b0rked products currently, getting to CMM level 4 or 5 would just mean we would consistently have b0rked products...

Re:CMM?

[sporty]

Erm, do you *want* to work in an environment where your work ("the process") is highly repeatable? Where's the fun in that?

I like having hair colour ;)

Seriously tho, these kinds of "process" thingys always give me the impression that they are implemented (and followed) in places where the management hasn't got a clue; in places where management believes that the "workers" don't have a clue; in places where the management believes that an employee cannot possibly *want* or *enjoy* his job, and has to be policed at all times.

Well, it's the difference of having no law, some law and too much law. Then add consistency to it. Process is there to prevent people from shooting themselves in the foot.. /mostly/.

I rather have management say, ok,it's time for a code freeze, QA gets the code, they do their thing, then another step, then another and then it's live. It makes my margin of error smaller, since things are done in a consistent manner.
It doesn't stop me from being an architect. It just means there are some laws in place.

ANd btw, if there's an opportunity to improve something, it doesn't mean i can't recommend it to biz people to include in a project. It's an opportunity a system analyst would include.. if they were smart.

Slides 41+42

[dmorin]

Pretty much sum up a huge portion of the slashdot audience, I think. I consider myself a good programmer who loves a challenge and wants to stay technical. Therefore I should look for technologies that will not be outsourced, teach myself those technologies via open source, and write articles / speak/ otherwise become recognized expert in that area.

In general I think the first half of the presentation just says why things are bad and why stuff like "rely on government to fix the h1 problem" won't work, so it's only really the second half that has the advice.

I think it's a little ambiguous that in the beginning it says the half life for typical technology is 7-2.5 years, but in the end suggests planning for the future 5-10 years out. That's pretty hard.

Or that specific skills, like "I'm a java programmer", are bad. Sure, all programmers *want* to use the line "A good programmer can pick up any language easily" but in THIS job market? Are ya kidding? Sure, 3 years ago we were desperate enough that we took C++ or Smalltalk people when we wanted Java. But in today's market do I really expect that people who want C# are going to take me the Java geek and say "Oh, sure, he can pick up C# no sweat?" When there are 500 other guys applying for the same job that already have C# and couldn't hack Java to save their lives?

I'd like to recommend the "write articles" approach, by the way. Quite a fun way to learn a new technology when you don't have a boss who is making you learn it but still need the motivation. The two problems are that a) there are so many people doing this that many magazines don't pay $$ anymore, just "recognition", and b) I've had recruiters chop the "Publications" section out of my resume because they claim that it's never the thing that gets you the interview (although you can certainly talk about it once you do get the interview).

Lastly, sometimes bad things happen to companies and a whole geographic region goes away. Don't blame yourself. My boss once told me that I was part of his baseline for the team and I was leaving that meant the team was gone. Well, the team is being dissolved, therefore I'm gone. But I can't have any hard feelings or say "Damnit I wish I'd learned technology X." I can only look forward toward my next job, whatever it may be.

Another Slide

[chemstar]

Build a professional friendship with your boss.

Re:Keep your job?

[pmz]

Focus on cross-platform languages and libraries.
You may not keep your job anyway, but you'll be flexible.

An additional benefit is that the concepts behind platform-independent technology are often behind the proprietary stuff as well. For example, if an interviewer asks about ASP, the interviewee can say "well, I'm familiar with JSP and/or PHP, which shares many of the concepts behind ASP, such as session management, ..."

Times Changes

[tds]

It's an interest presentation but it reminds me of one of those self help books! But it raised some very interesting points.

The discussion points mainly revolve around off-shore development, technology life cycles and bad economic conditions.

From experience off-shore development is not simple a matter of taking code off shore, it includes other large components of management, processes, extended organizational structures, cultural considerations and creativity. Which are often under estimated or completely misunderstood. In addition some activities are not a good fit for out-sourcing but are out sourced any way, by managers sacrificing long term success against short term needs.

I would draw the conclusion that there is a real trend out there for out-sourcing but there are real opportunities for people to fill the high value areas that I have out lined above. Most of all I think that creativity and innovation are very important factors and will always be in demand.

Technology life cycles are a fact of life for everyone involved in technology, the good news is that it creates an even playing field; the bad news is that it drives intense competition and disruptive change. The bottom line is if you want to stay in the business you have to make a commitment to constantly learning and keeping your skills up date.

The current economic environment may well be driving change in our industry, some of us may view as negative. But looking forward demand will return and we have a stronger base to build on as people and companies that get through this will be stronger and more competitive.

After all this is what we do...

Re:Do not document your code

[damien_kane]

Missing, unreadable, or best yet incorrect, comments in your code go a long way to assure job security. Don't make it too easy for them to replace you.

Alternatively, do what I do.
Although my code is not very well documented, I keep my bosses very close in the loop, moreso towards the end of develpment of a module, but still close enough that they know exactly what the code does and how long it took me to write it.
I do this at a high level, of course, but I make sure they understand my logic in solving a given problem.
This way they know that I can write code that's far cleaner and more efficient than anything they can write in less time than and equivalent would take them to write.
In this way, they are very happy with me (as I have redeveloped many of their processes in favor of efficiency), as well they have time to deal with the many clients.
Personally I don't think I have much to worry about in terms of job security.