Slashdot Mirror
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..."
Stop hanging out on /. all day! FP != a job.
I am, and always will be, an idiot. Karma: Coma (mostly effected by
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.
-
ping -f 255.255.255.255 # if only
I think
William Shatner...
Invented,
Power
Point
Operator, give me the number for 911!
Focus on cross-platform languages and libraries.
You may not keep your job anyway, but you'll be flexible.
The market for programmers slowly moves away from Microsoft. If you code in Visual Basic, you can be sure that only Microsoft-oriented companies will employ you.
Companies more and more switch to non-Microsoft solutions, meaning that they must switch programmers too. Knowing UNIX is becoming more and more of an asset; you might not know all the intricacies of bash or emacs, but if you code in perl you can be employed by Win/Lin/Mac/UNIX worlds...
Whenever possible, go for java instead of C#. Go for PHP instead of ASP. Learn to use as little platform-dependant code as possible.
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.
www.HearMySoulSpeak.com
Build a professional friendship with your boss.
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...
The main thing to focus on is value added. If most of your code is reused open source stuff you don't need to worry as much.
From an article I wrote:
http://xminc.com/linux/hottest_it_skills.h tml
Focus on Value Add
Value-add is mostly common sense - but common sense many IT professionals miss as their vision is clouded by technical details. How can you add the most value to your customer ? i.e. " What is my current/future customer/employer's biggest problem - and what can I do to fix it most efficiently and effectively in the long term ?".
Try to learn skills in areas that are "must have's" - a litmus test is " If the service was unavailable for 1-7 days could the company continue to function like normal ? ".
Many people focus on the value add marketed by vendors. For example a major corporation I know was thinking of moving their desktops from Windows 2000 to Windows XP. The true value add in this case is questionable. In general it is wise to question all claims from vendors for materials particluarly if they include the terms "legacy" and "upgrade".
Skills with Open Source software immediately make you of value. You can implement a File server for 500 users for only the cost of the hardware and consulting time ? A firewall/proxy server on a reused server ? Cost to the client = Nothing + Cost of your labor = a real win.
For programmers it is good to focus on learning environments that allow you to more rapidly produce useful quality code. Open source gives you access to tons of tested libraries that can speed your development time. Using dynamically typed and interpreted programming languages such as Python, Perl or LISP will reduce the number of lines of code you have to write and debug, and speed the code-compile-debug cycle, which can cut the cost of development(1).
Open Source tools give you access to the guts of the application - which allow you add more value to the customer. In tradional proprietary software solutions such as MS SQL Server if you have problems you need to pay a lot of money to call the vendor to get access to some hidden debug parameters that you can then apply to the application. You then try to interpret the debugging information, submit it to the vendor and then wait for a patch. This is much like trying to fix a car when you can't open the hood. Save the $20,000 part of the service contract and do it yourself. Often times this takes a mixture of system administration and programming talent.
Recognize most people adapt very slowly and typically resist technological change. For example replacing Microsoft Office with Open Office on 1,000 desktops may sound great in terms of reducing total cost of ownership. However, the truth is that the amount of time for retraining and resistance from the user community would probably make this project fail. Lock-in to proprietary systems is the athema to value-add.
Try to understand the economics of technlogical change(2), understand how to do a business proposal, and how to sell software projects. If you do - you are more likely to get " what you love " accepted as a corporate solution. Typically with sales of software solutions you sell to the business decision makers - not necessarily IT. Get the product or solution in their hands so they can evalgalize it and make sure you sell at multiple levels in the organization - have multiple people "going to bat " for you and your solution.
Avoid monoplies if possible. Software vendors can reduce the value add of the "total solution" that you are working on by arbitrarily changing licensing agreements and increasing prices. By using open standard or open source software that is not controlled by one company you ensure that you solution will have longer term value. Open software generally has a longer staying power than propretary solutions. Witness the staying power of ANSI C programming environment or the X86 hardware platform(3).
Different operating systems allow you to add different amounts of
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.