Posts tagged IT career

Which Programming Language Should You Learn?

The simple answer to this question is "all of the above."

At Lockheed Martin, you might see three different projects in three different languages - C, C++, Java. And parts of those three have you touching Python, HTML, CSS, Javascript, Makefile, and Gradle.

Interviewers for Google and Bloomberg will tell you their firms have similar philosophies on language. Largely language agnostic, using different things for different projects or use cases.

When you start out, you'll just be learning one language. Probably C++ or Java in an academic setting. I would recommend Python at Codecademy if you're a beginner.

Whatever that language ends up being, think of it as your starter Pokémon.

As you continue training, there are more Pokémon (languages) you'll encounter. Some you'll like, some not so much, and how much you use each will vary.

How much StackOverflow you need will vary.

There are strengths (Python with machine learning libraries), weaknesses (package management in C), quirks, and similarities (Java vs Javascript syntax).

Trying to make one language work for every situation will hurt you as a software engineer. You can (probably) do machine learning with PHP, but it doesn't have the libraries Python has for it. I have only the vaguest idea of how you'd start web development in C.

Sometimes I feel as if I haven't "mastered" any one language. But even the languages themselves keep changing over time (i.e. Java 9 is coming).

It's more about knowing enough to take on the projects you want to. I know Java deep enough for programming interviews, Python enough to bot online games, etcetera. There's not a point (or language) when the learning is done.

Considerations for Self-Driving Car Engineers

Udacity recently announced a self-driving car engineer nanodegree. There's a strong possibility, in my opinion, of getting relevant employment at the end. It'll cost you 9 months and $2,400.

The announcement email had me reconsidering my own career goals. It's relevant to me because my software engineering work for the last year has revolved heavily around autonomous vehicles.

Here are some conclusions I reached, and things for potential car engineers to think about.

Location

Where do you want to live?

If you work in the defense, aerospace, or automotive industries, it's very hard to live in a big city. The exception maybe being Detroit.

Why? What we engineer takes up a lot of physical space, for tinkering and experimentation if not the final products.

The most desirable places for someone with this nanodegree likely include Tesla, Mercedes Benz, and SpaceX.

Here are where those three employers seem to be putting their engineering people.

Based off searches of their career sites.

Tesla - Deer Creek, California; Fremont, California

Mercedes Benz - Sunnyvale, California; Redford, Michigan; Ann Arbor, Michigan; Montvale, New Jersey

SpaceX - Hawthorne, California; McGregor, Texas

Consider whether these are places you want to live. I currently live in Syracuse, New York and won't judge. 🙂

Side note: I mention SpaceX because I feel there's a big overlap in the content - see the below video which includes a lot of autonomy.

Advancement Opportunities

This will get a little more speculative.

Most of the places that will be hiring self-driving car engineers are not young companies. Therefore I think their approaches to advancing employees will reflect their age.

Maybe, regardless of overtime, performance, and/or accomplishments, it takes 3-4 years to get a promotion. (i.e. Software Engineer to Senior Software Engineer)

This is the impression on the defense side of autonomous vehicles. The younger the company, though, the less likely I'd think this is.

(Within reason - by "young" I mean Tesla or SpaceX and not some super fresh startup)

Testing

There's going to be an ungodly amount of unit and integration testing behind these self-driving cars.

If you look at the safety requirements behind human safety-critical spacecraft, you can get the idea. 100% path coverage.

That means every possible path through the code has to be executed at least once by your tests. It's stricter than branch coverage which is stricter than line coverage.

Say you've got the following...


if (b == 7)
{
    b--;
}
else if (b != 0
{
    b = 40;
}

if (a > 90)
{
    c = false;
}

System.out.println(a + b);

What are your paths? Whatever ends up getting tested here, maybe asserting the values of a, b, and c, you'll need to run those assertions through -

  • the first if with the second if
  • the first if without the second if
  • the else if with the second if
  • the else if without the second if
  • just the second if
  • none of the conditionals

The big question mark is how much of this responsibility will fall on self-driving car engineers. It might just go to dedicated software engineers in test.

When actual self-driving car engineer job postings begin going up, I guess we'll get a better idea.

Conclusion

When the self-driving car engineer nanodegree was announced, I gave it serious thought. As someone with relevant software experience already I can assume it'd be easy to get hired afterward.

However, mostly for the "location" reason mentioned above above, I'm not applying.

I do believe it would be better for many ~18-year-olds than going to college.

The Truth About Most of Corporate IT

At this point I've been in two full-time programming positions. I've learned how a handful of other firms operate through infosec work on the side, and testimonies from friends. My eyes are open.

When you're looking to work in IT, there are some things you need to be aware of.

Legacy code

I'm sure you've heard bad things about legacy code. It's often used as the butt of a joke by technical writers.

In the back of your mind, you probably think "I'm supposed to laugh at these jokes, however in reality things can't be that bad, right?"

Wrong. Things are that bad.

Legacy code = when our technology was first starting to get outdated and old (or practices were deprecating), instead of doing an overhaul or updates then, we ignored the warning signs and kept building onto it and now everything's a real shit show and you have to put up with it.

You want to go:

  • "Uhhhhh Internet Explorer shouldn't be the only supported browser."
  • "Tables shouldn't be used to style a page."
  • "MongoDB is the least appropriate database for financial transactions."
  • "Why can I perfectly replicate the session by copying unencrypted cookie data?"
  • "Netscape doesn't exist any more."
  • "There is presently zero browser support for this."
  • "Money shouldn't be a float."
  • And so on.

What does the rational-thinking person do when their house is falling apart? They fix the house. They wouldn't dream of putting on an addition. The house itself is falling apart, after all.

Legacy code is a house that's falling apart. And you'll be asked to build additions onto it. Watch out for rusty tetanus nails and falling beams.

Image credit - Dreamstime
Image credit - Dreamstime

Doing nothing

One of my close friends had a technical support internship this last summer. He would tell stories about how he sat at work all day, doing nothing. Like one call would come in a day.

I thought, "Surely he must be exaggerating."

Then I started my first programming position. For the last half of my first day, after a tour and lunch, I sat there doing nothing.

"This must just be a first day thing."

Then for the next couple days I did nothing. My supervisor came over at one point, and I go, "Is there something I'm supposed to be doing?"

I got some documentation to read and installs to do. That took me two days.

In the task / performance management system, the due date was a month out.

I would look at everyone else, at their monitors. They were talking about vacations or cookie recipes off Facebook, going on cruise websites, using their phones to go on Facebook, watching YouTube videos, whining, staring off into space.

Image credit - Giphy
Image credit - Giphy

For every 8 hour work day, I estimate about 1 hour of real work occurred. I got assigned like 2 hours of work a week because I was really new.

It got to the point where I would just stare at the clock. Every couple minutes that went by, I'd try to focus on the fact I was a dollar richer.

I couldn't stand doing nothing at work, this horrible music playlist going all day. Everyone sitting there, babbling or anesthetized.

After a month I hopped to my current job for an 85% shorter commute and 35% pay bump.

Related post: Stagnant = Obsolete

Assignments. Mental stimulation. A purpose. These are what I need at work.

At the end of the day, I want to feel like I've achieved something for the firm.

I don't care what I'm being paid. The true enemy of happiness is boredom.

You know in those vampire movies where vampires took over the world, and now the remaining humans are in pods so their blood can be harvested? That's what "work" / those jobs can be like.

doing-nothing-at-work
Image credit - Scified

Pimps

Who are the pimps of corporate IT? IBM, Citrix, Oracle to name a few.

And, like legacy code, a lot of positions will have you being their bitch. The whole programming department will be their bitch because they seduced management years ago.

IBM goes, "Hey we'll give you this stuff for free."

Then two years later they come back and go, "Yeah you need to pay for that now."

In that two years, because of all these tricks like IBM-proprietary XML mapping, your firm is now heavily dependent on IBM.

Image credit - China Divide
Image credit - China Divide

Which brings us to our next point.

Money burning

If you have a keen eye, you might notice millions of dollars being wasted. If you have open eyes. If you have one half-opened eye.

A lot of this money will go to the pimps I just discussed.

Then more of it has to do with employees. Obviously, when you're doing nothing, you're not making the firm any money.

They pay people $30/hour, you see them delivering maybe $3/hour of value.

How does that math make sense? It doesn't.

Image credit - technical.ly
Image credit - technical.ly

Your corporate overlords, though, have a lot of money to play with. A lot to burn.

Instead of looking at the efficiency of current employees, they think things will progress more rapidly by bringing on new hires. Tolerating, even grooming, the same behavior as old employees.

For example, say a rational person is in charge of software. Every day there's a production build of this one program, and every day it gets pushed to Big Pimp servers.

Big Pimp Inc. is charging some queer amount for every push. Every day Big Pimp is getting paid.

At one point, somebody was like, "Hey there's this open-source alternative we could run the program on. We wouldn't have to pay Big Pimp hundreds of thousands of dollars a year."

Now, Big Pimp made you write the software in such a way that it's heavily tied to their servers. But two enterprising employees out of the hundred-person department managed to get the software working on this open-source alternative.

The rational manager would go, "That's fantastic, Employee-That-Works 1 and Employee-That-Works 2. Everyone else in programming is now going to stop what they're doing, and you two are going to lead everyone else to move the entire codebase to this open-source alternative. Nobody works on anything else until we are no longer dependent on Big Pimp."

Because it would save the company money every day.

But that's not what happens. It's easier to keep spending the money.

The real manager goes, "That's cool. It looks like that was really hard to do, so type up half-assed instructions on how you did it. I'll tell everyone to install this open-source thing on their computer, and if they get time they can try to get the software working on there too. But they probably won't succeed. Not a big deal, we'll keep paying Big Pimp. The money doesn't come out of my pockets. Let's bring on more people."

Image credit - Hip Hop Wired
Image credit - Hip Hop Wired

The bathroom

The last place I want to have a discussion with anyone? Bathroom.

There are certain people at your work who, instead of just making eye contact and nodding to you in the bathroom, will go "HEYYY. HOW'S IT GOING TODAY?"

And you're not friends, or buddies.

You've never seen them. Unless they pulled this trickery before, burning them into your memory.

Just watch out for those people.

Image credit - Living Edge
Image credit - Living Edge

End note (silver linings?)

There are jobs where you don't have to put up with all of this, at the cost of your sanity.

You find them with (a) small, lean-and-mean operations or (b) big corporate players who have their act together. Currently I'm grateful to be riding in the second boat.

So how do you figure this stuff out, before it's too late?

For big corporate players, you can use Glassdoor or similar sites.

For small operations, they'll hopefully be more open to having you come on for a trial period. Even if it's just working there a week.

By small, I mean like 30 or less people. The experience I'm mostly ranting about was with a 1,000 person company.

By nature, when you have 30 or less people, there isn't really money to waste yet. People are more apt to have laser-focused stuff to do.

Anyway. What I'm trying to say is it's a jungle out there. Good luck to the job hunters and job jumpers.

Derp. (Image credit - Next Level Pro)
Derp. (Image credit - Next Level Pro)

Developing a Technical Web Presence

One of my relatives is going into computer science after just graduating high school. This advice is written with him in mind, but applies to all technical majors:

Develop a web presence.

In this field, that at least means a Github and LinkedIn. I also like Crunchbase.

The best time to start on these is your first semester. Your Github can then represent your whole history of learning to program. Plus the longer pages are up, the better they do with Google rankings.

github-crunchbase-linkedin

Myself as an example

Since last August, when I started this site, the Google results for "randy gingeleski" have changed immensely.

When you used to search me, you'd see all DGM videos and my old books. Neither helped establish professional credibility.

Now search results turn up this site, then Crunchbase, plus a bunch of images so people know what I look like, then LinkedIn and so on.

Screen Shot 2015-08-06 at 2.26.00 PM

Technical interviewers always ask about stuff from my Github or posts I've written here.

And (humble brag) every interview I've done has yielded an offer. Part of it is prepping heavily for each, part of it's making a good impression before you even step in the door.

Intro to Git and Github

Git is a type of version control software. At St. John's, they didn't touch on version control until my second-to-last programming course.

You should learn about it in your very first programming course. It's not hard to understand, and will help you immensely.

Image credit - Daniel Strunk
Image credit - Daniel Strunk

What's version control? It's like a "save" in a video game. If you get lost, you can reload from the last save point.

Every "save" in version control is called a "commit". You can "push" those commits somewhere to back them up.

And Github is a place to back up work you've committed with Git. To an extent, it's also a social place for programmers.

When applying for a programming job or internship, someone from that firm will (1) try to see if you have a Github profile and (2) look through what code is there to get a sense for your skills.

Screen Shot 2015-08-06 at 3.17.05 PM

Git + Github setup

  1. Sign up for Github.
  2. If you're a student and have a .edu email address, grab the Github Student Developer Pack.
  3. Learn Git from the command line (tutorial). There's a desktop app, but eventually you'd have to learn command line version control anyway.
  4. As you do your programming lab work, back it up to public Github repositories.

Preferably making commits between separate features, and trying not to commit things that don't work.

See my Github here.

LinkedIn

Make a LinkedIn profile, then go into your settings and play with them.

When people who aren't connected to you see your page, I suggest just showing them a summary and little else.

Screen Shot 2015-08-06 at 4.05.07 PM

For headlines:

  • Never use "Student at Blahblah University" as your headline. That's downplaying yourself.
  • Or "Aspiring Entrepreneur" if you've never started or failed at a business. That's something you're not.
  • Or something long and stupid like "Master of sales, lover of people | CISSP, ACE, WTF".
  • Just keep it short and sweet.

And the summary should be abrupt too. Everybody in the world will see this.

Here's one that's questionable:

linkedin-summary-example

For jobs? Things that are relevant to what you're doing now. Or your most recent job.

I keep my time at Turning Stone on there because I'm still involved with internet gaming.

I'm working as a software engineer. You'll see my affiliations with NYCM and Lockheed Martin.

My roles with the shady Jet Set Events, IgetCOMPED, and EventWizler don't make an appearance.

Don't be like this long job list that's going nowhere fast:

For your picture, make it appropriate to your industry. Tech is mostly casual dress now. You can get away with something like I have.

If you're trying to sell insurance, you probably need a picture in a tie.

Try not to look like a dweeb.

For connections, mine are people I would help and who I believe could help me. Otherwise they're ignored / deleted.

Two examples:

A: My cohort Evan Saez knows half the universe. Sometimes random people reach out to me because I'm easy to reach. We introduce each other to people.

B: A stranger from Binghamton connected with me. He designs casino games. If he hadn't turned out to be a lunatic, we could've gone to lunch and helped each other.

I don't have a lot either. Quality over quantity.

Skill endorsements and personal endorsements mean next to nothing.

See my LinkedIn here.

Crunchbase

What's Crunchbase? It's information on all the firms and players in the tech industry.

Make a page if you want to be a player too.

Like Wikipedia, it's curated freely by users and gets a lot of link juice from Google.

Mine has a short info blurb, links to my other web profiles, a bunch of pictures, and some press one of my projects received.

Screen Shot 2015-08-06 at 3.26.56 PM

It takes just a few minutes and helps establish you professionally.

See my Crunchbase here.

Miscellaneous notes

If any of your social media profiles aren't helpful to your image, make them private. Like if you're binge drinking or using explicit language.

My Facebook is private. There's nothing bad per se, but it's a lot of old pictures and family stuff. That doesn't have to be public.

My Twitter? Blank. Just a parked page.

Instagram? Travel and whatever. I feel like it's more intimate than my blog, which might come off as cold or intense at times.

If you have a common name like 'John Smith', use a different one. Make it 'JK Smith' or 'John Harold Smith' or whatever.

Luckily I only compete for 'Randy Gingeleski' with my dad.

Conclusion

You're a computer science student. You're expected to be proficient with computers.

When you're applying for jobs or internships, they will Google your name. It's not even a question.

Demonstrate computer proficiency by tightly controlling your Google results. Like I've written here, Github and LinkedIn are a good start.

From there, learn about domain names and hosting. I use Namecheap and Dreamhost for my personal stuff. Both services are heavily documented.

Good CS principle - strong documentation makes for code everyone can understand. Not just you.

Everything that pops up should make you look good. Someone who would be a pleasure to work with and deserves a lot of money.

Image credit - Pinterest
Image credit - Pinterest

Related viewing

Have ten minutes? Watch this personal branding course on Uncubed Edge.

I wrote about Edge before and now it's free. Great content on there.

Related posts

Stagnant = Obsolete

Tangibility & Computer Science

What Does Computer Science Have to Do with Business?

Stagnant = Obsolete

Recently I've gotten back into doing technical interviews, floating in security clearance purgatory for my normal job. You always get asked the same sort of stuff .
"What are you looking for?"
And I'm honest. I say that I'm looking to grow my technical skills, in the way coding for production allows. In the way being surrounded by and working with bright people allows. In the way incessantly writing unit tests for legacy code doesn't allow. There's a knowledge ceiling to JUnit.
Image credit - Raheja Tower Flickr
Image credit - Raheja Tower Flickr
One of my interviewers, a software architect, had a solid response.
"In our industry, anyone who's stagnant becomes obsolete."

Unproven

When you haven't done full-time industry work in the technical field, you're unproven. No matter how much stuff you have on your Github or how many contracts you've worked. That doesn't seem to hold much weight with interviewers. Coding with a team for production is different. This has become apparent in how much I end up babbling about my software engineering class from St. John's (CUS 1166, spring 2015 semester). That's the only time I've truly coded with a bunch of other people. Wide range of skill proficiency. Havoc over Subversion. Frustration abound. In the end we made this ugly thing called menusearch, but it worked. Being a full-time software engineer or developer is a whole bunch of that. Maybe more people who know what they're doing. What you work on for your first year in the field, out of school, could dictate your entire career timeline.

Two different job scenarios

Here are two very real scenarios. For both, you're a recent BS Computer Science grad, only planning to be there a year, and Java's the vehicle of choice. Any mention of "new code" means test-driven and heavily documented, similar company culture. Salary's algebraic because it's highly dependent on location.
Image credit - EOG
Image credit - EOG
First scenario - huge corporation, lots of name recognition. Salary offer of X. Day-to-day you write unit tests on legacy code. It's implied that after maybe a year and a half you'll be trusted to start writing a bit of real code. The new code to maintenance split is 20/80. Second scenario - sizable firm but still growing, concentrated to your state, hardly any name recognition. Salary offer of 25% greater than X. Day-to-day you're writing a lot of new code, all of the company's software is newer in-house stuff. You have a supervisor who mentors you. Since everything is fairly new you get to suggest and try out new technologies where appropriate. The new code to maintenance split is 60/40. At the end of the year, which scenario results in the greatest market value bump? This could pace the trajectory of your whole career.

"Why can't I do the same thing forever?"

If you never want to expand your professional skills, there's always McDonald's. You can make $15/hour by 2021 and pretend inflation doesn't exist.
"Workers are hopeful their lives will change with the dramatic increase in their pay." Okay. Image & quote credit
Image credit - Syracuse.com
Meanwhile in the tech field... What were traditionally different business departments - telecom and IT - have merged as phones became computers. Certain facilities stuff, like HVAC and surveillance, will likely follow. Unified digital infrastructure. The in-demand languages and technologies are shifting all the time. Here you have Github trends:
Image credit - RedMonk
And then job growth trends, ten languages altogether:
Programming-Job-Trends-Traditional
"Traditional" languages. Image credit - Indeed.com
"Modern" languages. Image credit - Indeed.com
Change occurs even within languages themselves.
  • Major new versions - i.e. functionality from HTML4 to HTML5, setting up the death of Flash Player.
  • Repurposing - i.e. Java, originally intended for programming hardware like VCRs, is now a force of nature from corporate to mobile.
If a programmer from 1985 time-traveled into a modern software shop, he'd be irrelevant beyond the basics. Literally BASIC.
Commodore 64 Programmer's Guide, table of contents.
Commodore 64 programmer's guide, table of contents.

Conclusion

Being stagnant in the technical field makes you obsolete. Nothing's evolving at a pace quite like technology. Those of us that work with it have to evolve too. Success in doing so yields increasing average earnings. This can be realized via job hopping or internal promotion. Failure to do so results in decreasing market value - until zero.

Tangibility & Computer Science

Something I think every computer science student will eventually ponder is the tangibility of what they're doing.

Programming and algorithms definitely. Networking as that becomes increasingly wireless. Engineering as everything gets smaller or implanted into body parts.

(Image credit - David Icke)
(Image credit - David Icke)

My existential crisis

Well, an existential crisis is where you question the foundations of life. Not sure what the proper term is for questioning the foundations of this work.

When I first learned to code (C++ course in high school), it was like magic. I was thrilled with forcing the computer to obey my commands. Even if it was just making fizzbuzz print to console.

College beat that honeymoon period to death. Working on my own projects made me content.

Things got shaky when I did my blackjack certification (2014). I would drive home from class wondering if I'd "chosen" the right "path" in life.

Quotations there to combat the you-can-suddenly-be-an-astronaut-at-80-years-old-if-you-really-want-to argument with ambiguity.

When you're dealing cards, your work is right there in front of you. Manipulating cards and cheques. You can gauge how well you're doing by how pissed off the floor supervisor is. It's a trade.

My dad is an electrician, also a trade. You can touch (sometimes) the results. We'll drive by some train yard, he'll say he made all the lights work.

Computer science is... in the computer. So:

These aren't all bulletproof points, but were what I struggled with at that time.

Maybe you have too or maybe they look like UNIX beard ramblings.

unix-beard
(Image credit - The SANgeek)

Relating to computer science tangibly

This is where I am now.

Code, bits, bytes - it's like molecular architecture version 2. Evolving a lot faster than we can organically.

Most of your work might go unnoticed. I imagine the average Facebook user can't begin to understand how much logic and creativity makes that service possible. They'll still go on there 20 times a day, living vicariously through their "friends."

Your work might get phased out. Maybe you worked on the AOL web browser a decade ago, now it's webmail and clickbait for older people. You were still part of how most people got online for years.

(Image credit - ExtremeTech)
(Image credit - ExtremeTech)

Computer science makes it possible to call the police or fire department from virtually anywhere.

To get online (networking), order a pizza (papajohns.com), and have a family movie night (Netflix). Then share it with the whole world if you want (Twitter, Facebook, etc etc etc).

To track and disable truck engines from flying laser beams.

https://instagram.com/p/0FwHFnQJwK/

There's now some level of programming and networking at play in just about anything. Microwaves, phones, TVs, cars...

One person's contributions can play a key role in affecting millions or billions. Helping save lives or the world.

Closing

It was really stupid of me to get into a rut about this when I did.

If you're in a spot like that now, just look around. Our present way of living relies on computing.

That's pretty tangible.