The Corporate Hustle

In new corporate hires, the most common question I get asked as a developer is, "Do you think I can be a developer?".  The answer is not always a simple yes/no. Although I am a big fan of binary decisions.  The game of development is always about writing the best code, or solving the most complex problem. At times, I wish it was. The game of development depends on the environment that you are in.  Let's assume you are not a CEO of a company of 1. You landed an entry-level job as a developer working on someone else's code and trying to figure out the insanity that they wrote. Here are specific steps to help you on that side of the game:

Developer On-Boarding Process

1. Run the code and see what it actually does
2. Ask what the code should do, (1 and 2 are rarely the same)
3. Trace the code from step 1 to see how the code flows
4. Add a new function and see if you can call it in the right workflow without breaking anything
5. Write a unit test to verify your new function/feature.

That is the process for learning a new code in 5 easy steps.  That just takes time to get that process down pat in multiple languages, but you'll get there. Here are the hard parts of the corporate game:

Developer Corporate Questions

• How do I sit quiet in a 3 hour planning meeting when I could have solved the problem in the first 15 minutes?
• When is the right time to speak up when you hear bad decisions being made, but still not offend anyone?
• I thought I was hired to write code, not build environments, write build scripts, debug AWS deployments, is that not true?
• How can I get my work done when everyone is scheduling a meeting that is "mandatory" for me to attend?
• Why are there so many meetings when the decision is perfectly clear to me and if it doesn't work we can fix it?

Those are the questions I have heard from students time and time again after they get their first job. They are overwhelmed not by the coding challenges because that is what they went to school for. They are overwhelmed by the meetings, the political landscape, and all the assumptions that they know every source control process, every continuous integration application, how to deploy to qa, staging, and production in an automated fashion to AWS, Azure, Google Cloud, Heroku, Firebase, and on-premise private cloud infrastructure. Those are the real-world questions that happen usually in the first month of employment.

The Answers

The answer to those questions are NEVER binary. I wish they were. I wish that a decision could be made in under 3 minutes, and we go in a direction and see if it works. From a developer standpoint, prototypes are equivalent to those meetings. Let's prototype 4 options and see what is the easiest to maintain, scale, secure, and deploy. That is how a developer thinks. Corporate America does NOT think like a developer. They think differently. Often you will need to identify all of the obstacles you may encounter one day as you develop your code. You to have an answer for every problem they could possibly think of. My favorite was, "what if this is browsed in China, in a proprietary browser with JavaScript disabled?". I responded, "It wouldn't work at all. Any other questions?". That seemed to me like a perfectly sound response. Apparently, it came across as sarcastic and rude. LOL. I can see that now, but I still stand by my response, it was accurate and allowed for any follow-up.

When to speak up

So let's talk about the time to speak up in a 3 hour planning meeting. If you are an entry-level developer and this is your first job, you probably don't know what you don't know, so just listen. Take notes, and listen. You can process your solutions during this meeting on paper. However, you shouldn't really speak up unless you are sure what you are about to say. If you present questions, you need to have a solution ready quickly after. Also, you should have multiple solutions, people like choices because then they think they made the decision and feel good about the direction.

It comes down to one thing: Everyone wants to be heard.

The problem is not everyone should be heard. Some people are idiots and have no idea how technology works. It is often that those idiots have more experience in the industry and may know more about the client rather than the technology, so those people who seem to be idiots at first glimpse are wise beyond your comprehension at this time in your career. That is not always the case, some really are idiots. :-)

The best thing you can do is deliver prototypes, listen a lot, and talk with other developers at the company. Do your job.

For next time, the next topic will be "I'm a coder, not a devops guru, what am I doing?"

Go Build Something Amazing! Thanks for stopping by.