How would you threat-model your programming job? (7)

1 Name: #!/usr/bin/anonymous : 2009-03-12 06:36 ID:hqXCSnHR

So a few weeks ago I started reading about threat modeling with regards to application security. A while later I started to think...with the economic downturn, how would you threat-model your programming job? There have already been layoffs at my company, and if they are even happening at Microsoft, you know that it probably can't hurt to be a little defensive about your career at this point. What would be some easily-defined, auditable things that you could do to give you the edge over your peers when they're applied consistently? What could you do right now to prevent yourself from being picked to get laid off later?

A few pointers that should avoid some bothersome arguments:
1. Yes, I know that any of this stuff that we suggest is not a guarantee that you won't get laid off and the management is unfair, etcetera. I'm familiar with this because I've suspected the management at my (USA) job is discriminating against non-H1-B visa workers. But let's stick to what we can do. Let's go for a standard of "doing this is better than not doing it".
2. Let's avoid vagueness. "Try and get an architecture position" is probably obvious to us by now. How is that done? Is there some kind of counter-intuitive wisdom we don't know about making that happen? It would be great to know some things to do such that we know when they are done.
3. We know they won't apply in every position, in every case. They might even conflict with each other, or require prioritizing or balancing. We'll be smart enough to consider that.

I've got some ideas I might chime in with later...just little things...

2 Name: #!/usr/bin/anonymous : 2009-03-14 06:30 ID:ujdff/u0

Delete all comments in your code and make all subroutine and variable names meaningless (or meaningful only to you.) When possible, port your code to a language that no one knows and no one will learn, like Haskell.

3 Name: dmpk2k!hinhT6kz2E : 2009-03-14 16:20 ID:Heaven

I work only for startups. One of the myriad benefits is that I'm not going anywhere until I want to or the business dies. The first in under my control, and the latter is usually seen from a distance easily.

That, and having healthy savings and several other options when I'm fired. Losing a job is inevitable, and I look at it as an opportunity do things I can't do when I'm working full time.

4 Name: #!/usr/bin/anonymous : 2009-03-14 20:16 ID:pSrlQRGH

Hare's a very good resource regarding you question: http://mindprod.com/jgloss/unmain.html.

It works for me! No way I'm getting laid off, it will take years for a good programmer to understand the mysterious ways our system works. Although, I can't really take credit for it, I even made it a less of a mud-ball it was.

Other option, that should work, if you have sensible management - be a better programmer than the other employees.

5 Name: #!/usr/bin/anonymous : 2009-03-17 22:04 ID:vFPwErZo

>>4

god bless you sir, that essay is {hilarious = hilarious + 1}

6 Name: #!/usr/bin/anonymous : 2009-03-27 01:11 ID:A6KN2yoJ

>>4

In C:

  1. Unroll all loops. I know, I know, most compilers these days can do some of that for you, but I also know most (of the new ones, at least) programmers can't.
  2. Sneak a Lisp interpreter in there. Hell, sneak a Lisp interpreter, an Awk interpreter, and a Lua interpreter, and make them all talk to each other.
  3. Write your own database. Or take an open source one, and make it completely different than any out there, as far as syntax goes. 50 lines in the special DB to one line in SQL is almost sufficient.
  4. Make copious use of version control, but don't tell anyone that you're doing it. In fact, keep the version control system confined to localhost (and enforce it with firewall rules).
  5. Write a lot of erroneous documentation, but don't release it. Print it out, keep it in your desk, and all over your hard drive. This won't protect you, but if they do make you redundant, it'll make for at least a bit of revenge.
  6. Inline ASM doesn't have to be painful. Just disassemble the code you've already written in C. See rule 4.

7 Name: #!/usr/bin/anonymous : 2009-04-03 20:58 ID:Heaven

seen people do similar stuff

they get fired/laid off first

it's called "not being a team player"

welcome to $REALITY

Return Entire thread Last 50 posts
This thread has been closed. You cannot post in this thread any longer.