Do IT before you get done in by IT.

The different types of people who program: StopGap coder, Programmer, Developer and Fullstack Developer

So, as usual, I’ve spend my time reading on the internet about all crazy things (and I mean CRAZEEE). But sometimes I come across nice articles, written decently and defining their principles succinctly. So, today I’m jumping on their bandwagon and giving my opinion of the above topic: The different types of people who program. (I’m not dealing with quality of programmers, as that’s a totally different topic.)

The articles that got me thinking were these:

 

Love the articles, guys, well written indeed.

Now, here’s how I’d put my opinion forward:

  1. The concept of Hackers and Crackers
  2. StopGap coders & Noobs
  3. Programmers (coders)
  4. Developers
  5. After this
    1. Full stack developers
    2. Software engineers / designers / architect
    3. Programming / hacking demigod

1. The concept of Hackers and Crackers and Phreakers

In the oldest concept of the word, computer hackers are (unfortunately correct) the guys breaking into systems. They then modify the systems to get to other systems, using the current system as a springboard (basically to help mask their trail). Their primary motivation is freedom of information / knowledge. The break in, take a trophy (to prove they were there) and then either forget about the system or use it as a bot or node.

But nowadays, hackers are guys who hack system together. I’d put modern day hackers (who don’t break into systems for fun) as developers or higher.

But I’d prefer a hacker over a cracker any day. Crackers are hackers with the same intentions as a hacker, but also with the added malicious intent to damage systems / degrade performance / steal.

Then, phreakers. These guys are hackers who specialise on the telecomms industry. They hack phone lines, wifi signals, cellular lines, SMS and these days mobiles (GET YOURSELF AN ANTIVIRUS & FIREWALL NOW!).

  • A phreaker is a hacker or a cracker.
  • A cracker is a hacker and can also be a phreaker.

2. StopGap coders & Noobs

On the lowest rung of the [professional] development tree you get the IT guy with programming knowledge, I call him the stopgap coder and the Noobs. Often starting and ending their careers as noobs in programming. Never writing more than a script to map network drives or change IP addresses or something that doesn’t really need compiling. Their favourite coding IDE…. notepad.exe (and don’t laugh, mine is Textpad…even though I’m quite a bit past Noob level). Seldom leaving the comfort of the localhost. Never understanding the joke “There’s no place like 127.0.0.1”.

I have a saying about these guys: Half of them should’ve been bartenders and half of bartenders should’ve been stopgap coders. I don’t say this to be nasty, but I’ve found that the motivation, determination and focus to code on this level isn’t what is required to become a Full Stack Developer.

My advise if you’re here? Don’t EVER stop learning. Don’t ever stop thinking differently. Demigod Linus Torvalds also started here, albeit before most of you were born.

Bonus content: To really design a system, you need to be able to answer the following question (approximate answer at the bottom): How do you make a cup of coffee if you had to write it down in pseudo code?

3. Programmers (coders)

These guys are the grunts. They’re the guys who do the heavy lifting. If we were in the construction industry, these would be the guys who actually work on a building, hands-on and in the trenches. They’re an army (if they are junior to mid level coders) or they’re a fistful of fury if they’re senior programmers. These guys come in two flavours, the specialists and the generalists.

A specialist coder focuses on a single area of competency. They’ll be people who write your port connectivity protocols. Or they’ll be SQL / DB specialists. Or they’ll be GUI experts. JavaScript fundees. CSS Ninjas. HTML markuppers. They’re the people who write the stuff that doesn’t come naturally to everybody. They’re the guys who can con—vince a computer that it’s wrong. These guys understand the overall system’s big picture and code accordingly.

A general coder is a jack-of-all-trades, master-of-none (or master-of-most in their own minds – experience). They can design and build you a GUI with a mySQL DB plus a bit of stuff in between, but they’re not always aware of all the aspects. Where their strength comes in is that they code sections. You give them a database abstraction class to write and they’ll do it, after some research. It won’t be the fastest, it won’t always have error checking, it won’t be the smallest, but, by dang, it’ll work ! And then, you can give them another class to write. Or rewrite, which is another part of their function.

On small scale projects, this is usually where we end the line, as most senior programmers can also be developers to a large degree.

4. Developers

Damn, I love this video of Steve Ballmer: Youtube link. Developers developers developers! In a nutshell, I wouldn’t be amazed he’s a hardcore developer. Probably full stack. Serious Ooomph! Will have to read a bit.

A developer is a different type of beast. He designs in pictures. He talks to himself while he designs. Probably paces the whole building full. He sees code on different platforms just before he falls asleep at night. He understands the different technologies that the system is comprised of, but isn’t necessarily proficient in all of them.

As the term “develop” states: grow or cause to grow and become more mature, advanced, or elaborate.

Developers develop. And they code. And they have a clear understanding of what needs to be the final product, even if their final delivery is part of a larger system (I mean Sharepoint is built alongside IIS afterall).

Sometimes they work alone, sometimes in a team.

This is a tough job, I gotta tell you. You have to speak Biz language. You have to speak tech. You have to speak idiot and be fluent in many technologies and programming languages. You have to be able to split the Nile and catch sunlight in one hand. And, then you need to put that all together so nothing falls apart. You need to be calm. You need to be focused. You need to be able to think from all sides of the system (user, OS, DB, security, crons, daemons, protocols and more).

Especially if you’re a lead developer on an enterprise system.

And, guys (and gals), this sounds like a tough job, cause it is, but the satisfaction from this level is euphoric. Sitting next to a user and getting compliments as to every aspect of your system is an incredible feeling. Watching as your system proliferates through the world is even better. Imagine Mark Zuckerberg must have felt when FB hit 20 000 users… then 100 000. Then 1 000 000… then 1 000 000 000… And still growing.

6. What’s next

Full stack developers.

WTF is that? Well, typically a full stack developer is someone who is a developer… with a few twists. These guys are usually one man armies. The walk in, kill your annoying fly with a brick and then walk out, never to be seen on the yellow brick road again. And, when you get a full stack developer, you don’t need so many developers, because one of these usually cover many of the other disciplines.

A good way of describing this is someone who can write CLI (Command Line Interface), bash scripts, apache, OS level understanding and experience, GUI, database and CGI / web scripting languages. They can develop across platforms (to a degree) and have (usually intimate) knowledge of all the technologies used in a system.

Usually FSD guys have awesome programming jokes.

Software engineers / Architects

Are different people again. They also think in pictures and in relationships. Some use to be coders / devs, some haven’t written code since university or college. Irrespective, these guys usually design a system. Seeing each component for what it is and then documenting the requirements (specs) which each team (if there’s more than one, else just team) will use to develop the system. Technical knowledge is usually high. Requires good people skills cause they gotta talk to people to figure out what’s needed.

These guys are the guys who design shit. Whoops. Yes, they design things. They basically say “OK, we want this, how’re we going to do it.” They usually come from programmer level and above, but sometimes they’re business analysts that give you a (written!) notepad with a lot of sketches in it and then claim architect status or system engineer.

If you’re lucky, your senior / lead developer is also your architect and engineer. They already know how system work. They already have experience with how businesses work and they know how people work.

My favourite saying (a bit modified) is: There’s a continual race between the universe and software designers. The universe is always churning out better and better idiots. And software guys are always trying to make their software more idiot proof.

Demigods

These are recognized people who have made tremendous contributions to the community (usually the hacking community). These guys (albeit not rich) are by far famous in the IT world. Most famous to normal people I suppose is Linus Torvalds, creator of Linux. Where would the world be without Linux? A Microsoft hell or heaven (whichever you prefer) with a refreshing splash of Apple(s).

These guys are the shiz. They’re the guys you see on TV. Except the guys on TV are fakers and live in the AFK world and usually personify PEBKAC, leading to ID-10-T problems (aka the loose nut behind the keyboard).

Now for the programming version of making coffee

First, the short answer to make coffee: Go to Wimpy or visit a friend.

The long answer:

DECISION: is power to the house on:
NO: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy
YES: continue

ACTION: get result from subroutine: check_for_and_take_coffee_out_of_cupboard
IF NO_COFFEE: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy

ELSE_IF NOT_ENOUGH_COFFEE: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy
ELSE: continue

DECISION: get result from subroutine: does_kettle_have_enough_water
NO: goto subroutine: fill_kettle_with_enough_water // should have subroutine to check if water is on
YES: continue

IF I_DRINK_SUGAR:
ACTION: get result from subroutine: check_for_and_take_sugar_out_of_cupboard
    IF NO_SUGAR: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy
    ELSE_IF NOT_ENOUGH_SUGAR_BUT_IT_IS_OK: continue // important to have before the next option
    ELSE_IF NOT_ENOUGH_SUGAR: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy
    ELSE: continue
ELSE: continue

IF I_DRINK_MILK:
ACTION: get result from subroutine: check_for_and_take_milk_out_of_fridge
IF NO_COFFEE: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy
ELSE_IF NOT_ENOUGH_COFFEE: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy
ELSE: continue
ELSE: continue

ACTION: get result from subroutine: check_for_enough_clean_cups_and_teaspoon
IF IS_AVAILABLE_BUT_DIRTY: goto subroutine: wash_cups_and_spoons
ELSEIF NOTHING_IN_THE_HOUSE: goto subroutine: decide_if_you_really_want_coffee_or_go_to_Wimpy
ELSE: take out clean cup

ACTION: goto subroutine: put_clean_cup_on_surface
ACTION: goto subroutine: add_amount_of_desired_coffee
IF I_DRINK_SUGAR:
ACTION: goto subroutine: add_amount_of_desired_sugar
ELSE: continue
ACTION: goto subroutine: add_amount_of_desired_water
IF I_DRINK_MILK:
ACTION: goto subroutine: add_amount_of_desired_milk
ELSE: continue
ACTION: goto subroutine: insert_teaspoon_and_stir
ACTION: goto subroutine: place_teaspoon_in_sink

IF I_DRINK_MILK:
ACTION: goto subroutine: put_milk_back_in_fridge
ELSE: continue

ACTION: goto subroutine: place_coffee_back_in_cupboard
IF I_DRINK_SUGAR:
ACTION: goto subroutine: place_sugar_back_in_cupboard
ELSE: continue

Result: One steaming cup-a-java (8 as 64bit – more IT whit)

When youngsters ask me to teach them to code, I always put then through this “make me coffe” test. I helps them understand a bit more as to how program writers think. And, some of them that I put through the test usually wind up making me a cup just to follow their brain processes. We see details (as a result, 80% of a code environment is usually taken up by error checking and processing, but I like to keep that down to about 40%).

Share

No Comments Yet

Leave a Reply

Your email address will not be published.