Since I wrote my article on how to Think With A Programmer's Brain, I've gotten continuous requests for information about starting out in the tech industry.

So, I decided to research and consolidate some of the information.

The core of this article are some things that can make your first days on the job stand out.

Define Expectations

There are some simple question that rarely gets asked. They can provide great insight into the job expectations.

They are simply ...

1. What should my first six-months look like?
2. What should my first year look like?
3. What should do I do to get the next level?

I can honestly say that I've never asked any of these and absolutely should have ... so many times.

In the next section, I talk about asking questions in public. I personally feel that these types of expectation leveling questions should be one-on-one (in private) with the hiring manager and/or team-lead, since the questions are about you and your expected performance.

Questions

Ask your questions in public, not in private.

It is tempting to ask questions directly to a friendly Senior Developer. It feels safe and not as intimidating ask speaking in front of others.

You will get better advice when you have a number of people looking at the question and weighing in.

That old school adage comes to mind here. If you've got the question, it is almost guaranteed that someone else has the same question.

Be curious about everything. Ask when you don't know what something is, even if it seems like you should know. Not only is this a way to learn, but it is a way to normalize the idea that people do not know everything.

To what degree are work cultures at tech companies actually open to having their methodologies questioned or potentially improved upon by a junior developer so early on? I know in an ideal world we are all open to improvement and different perspectives but I’m curious about your real world experiences with this.

Almost all of the companies I have worked with are open to questioning of their methodologies and processes. They are willing to talk about how they got to where they are.

The number of companies that will actually change is somewhat smaller, even if they are presented with something better. Change is painful and hard. This shouldn't keep you from asking the question ... if change does occur for the better, it will be because of your effort.

Company Domain

Learn your company's domain. Ask questions about every ridiculous acronym or the crazy jargon you hear and don't understand.

Having worked with the US Army I can tell you that acronyms abound and can challenge even the best of us to keep up with them.

First, ask a question. Is there a glossary of terms available?

If not, a glossary should be created that captures the key terminology that is used within an organization and can help keep variations, definitions, and acronyms straight.

Deep Dive

Find some part of the development ecosystem that you are interested in and can do more of a deep dive on. This will help you gain confidence as you learn a lot about that subject.

My deep dive was into a legacy scripting language. It had to be converted to JavaScript to run in a browser. The subject matter expert (SME) that designed the language had died years before. I knew the theory of designing a language, but hadn't attempted anything like it before.

I dove in.

A month later I looked up from my screen with a working language.

And, I will say that if I had to list the code that I am most proud of this scripting language would clearly be at the top of the list.

Imagine how it will feel when you get when a Senior Developer is asking about what you have been studying ... and you have the answer they need!

Do not just focus on that one area. You want to know some about a lot of things, and a lot about some things.

Understand Why

Instead of doing things blindly, try to understand the why behind what you are doing.

It might seem like this should fall under "Asking Questions," but I think there is a difference between getting an answer and determining why that is the answer.

I had a client that refused to utilize modern tooling. They had outdated code. When I asked about it, I was told simply, "that's the way we do things."

Knowing that modern versions of the code were smaller, more efficient, and actually had some security fixed, I took it on myself to discover why.

Several conversations later, I found that the individual I had first asked had watched his code fail at a critical time, just after a version update had occurred.

His reluctance to change versions could be understood at that point. I approached the change from a different direction (using it as a means to improve testing) and was able to get the changes in place that needed to occur.

It is absolutely alright to question why a certain process or technology is used. If the answer is, "that's the way we do things," dig in for more information if it is appropriate. There might be a better technology or solution that an inquisitive mind might uncover.

Understand Perspective

Do not forget that you often bring a perspective that others don’t have.

The best example I have here is a project I did at a conference. We were tasked with hacking a drone. There was a great interface layer available that got us up to speed quickly.

What I found interesting was the variety of perspectives that achieved the same results ...

• I wrote a web site that I could use the AWSD keys and up and down arrows to control the drone. I put in a means of developing pre-designed scripts.
• A co-worker connected his drone to a Wii-Nunchuck controller.
• Another individual used an XBOX controller to control his drone.
• A fourth individual developed a script that scanned with the drone's camera and read a QR code that provided height, distance, and direction (a vector approach).

The diversity in perspective was amazing.

Take On The Dirty Work

Another thing that helped me build relationships with more Senior Developers on my team was to just dig my teeth in and do the most absolute dirty work needed.

At one of the companies I worked for we had a bug that kept showing up. It seems to occur somewhere around one in 1,000 times the page loaded.

Several extremely intelligent developers, including myself took on this bug over a six month window. We all failed miserably.

Then, came the Intern.

She saw the card in the backlog and asked me if she could look at it. I managed to not laugh out loud and said she was welcome to dig into it.

Three days later she came by to show me something.

She solved the issue. In fact, she had built a Unit Test to prove she could replicate the bug that had stymied the best of us.

The issue and solution wound up being trivial, but she definitely made an impact on me. I'll never quite forget that intern that was persistent enough to trace every call on refresh for three days in a row.

Take on the dirty work, it does get noticed.

Daily Updates

If you're not on a team that does a Daily Stand Up, here's a way to provide daily updates.

Ask if there's somewhere you can post your daily updates on what you've been doing; somewhere where they are available but not annoying. This is a good way to track your journey in public so others are aware of how you are doing. Often they will notice patterns or areas you are struggling and offer to help.

Documenting your journey will make it easier for the next junior. Imagine what would have been nice for you to know, and write it down.

Onboarding Documentation

If you are allowed, ask to take control of the Onboarding Documentation. I often suggest teams take this approach. It is generally documentation that people update when they have time (I rarely do, and I'm one of the few that would actively work on it at times).

This takes some weight off the team. As you see deficiencies in the documentation and update them. This will have an impact.

This work will be noticed and future employees will appreciate it, as well.

It could be argued that this could fall into the "Take On The Dirty Work," but given the documentation's importance it is more a matter of "paying it forward," starting a pattern that will pay tons of benefits down the road.

Conclusion

We have looked that the following eight things that can be done to improve your impact as you start work.

1. Questions
2. Company Domain
3. Be Curious
4. Deep Dive
5. Understand Why
6. Take On The Dirty Work
7. Daily Updates
8. Onboarding Documentation

I have always felt that these are about doing the right thing. They are often things that are simple, but carry a heavy impact within a team or company.