Archive for the ‘Career’ Category

Being mediocre before being great

Do you have an ambition to be a top performer in your job? Do you have a hero who you want to be like when you grow up?

I have an ambition to be a top performer in my job. I have a picture in my mind of what success will look like, gleaned from reading and looking at leaders around me. Someday, I say to myself, I’ll be able to provide trusted advice on technical direction that improves the productivity of an entire department. Someday, I’ll be able to deliver a talks or write blog posts about my work that inspire and motivate others, and provide value to their careers. This is a vision of greatness.

However, before I can be great, I must be mediocre. The thing about picturing great success is it doesn’t tell me how to get there. I need to break down an ambitious and, to be honest, at times overwhelming, goal into manageable steps. I need to build the discipline to get stuff done. I need to be okay with failure and mistakes.

I’ve already taken some career steps:

  • I used my performance review as an opportunity to ask for a raise in writing. After listening to Kalzumeus Podcast Episode 12: Salary Negotiation with Josh Doody, I realize there are a few things I can do better next time, but it was a good first step.
  • I participated in my first story mapping/story authoring session. This is an agile practice for gathering user requirements in the form of a flow-chart-like diagram.
  • I started sending weekly updates to my boss. These detail my progress on company objectives and the general sprint work. See: Selling Yourself: How by John Sonmez.

By themselves, these steps don’t turn me into a software developer guru, but they are a step in that direction.

Another post on being senior

Last week I wrote about how senior developers take the initiative instead of waiting to be told what to do and how to do it.

Sarah Mei had a great series of tweets on the differences between junior developers, mid-level developers, and senior developers.

  • Junior developers need help figuring out how to do things. They don’t have the research skills to get things done on their own.
  • Mid-level devs have figured out the how and are starting to get the why, though they don’t communicate their ideas very well.
  • Senior devs long since figured out the how and the why. They have their own ideas and can get other people to go along with their ideas.
  • There’s a limit to how much impact one person writing code has. Senior-level impact is when you can change how other people write their code.

Tweets: 1, 2, 3, 4 (edited slightly since I don’t have a 140 character limit and I can add formatting)

I’m going to piggyback off what Sarah Mei wrote and add my own two cents.

First, the how. How is the basic mechanics of getting your job done. Say you need to fix a locale bug. The how is figuring out which source code is causing the behavior, and finding the file and line of code to modify. It’s also reading the docs to understand how locale is supposed to work.

Sometimes you get stuck. For example, you realize that in Electron, the renderer processes have access to navigator.language, but the main process does not. How will you make sure that the main process gets the correct locale?

I heard a rule of thumb that you shouldn’t let yourself be stuck in the how for more than 15 minutes. If you get stuck too long, you should ask for help. This is where the rules for asking questions can be helpful: provide context to what you’re trying to do, explain what things you tried, and show a concrete example. Eric Raymond has a great document “How to Ask Questions The Smart Way,” of which I would point to the “Be precise and informative about your problem” section.

As you grow your expertise, you won’t get stuck as much, or (more likely) when you do get stuck, you can get unstuck after doing a little bit of research on your own.

One time I asked a coworker how Java handles integer overflow. He said, “I don’t know, let’s try something,” and proceeded to write a quick unit test and used the IDE’s debugger to show the result. I felt sheepish because I realized I could have done this experiment on my own.

Programming can be a lot of fun when you can quickly write some code to prove/disprove a theory of how something will work.

Next, the why. I think a good example of this is clean coding. At some point, somebody wrote a bunch of spaghetti code, so now we have a best practice of writing modular code with loose coupling. At some point, somebody wrote the entire system using singletons, but then when it came time to maintain it, it was like dealing with a bunch of global variables, and nobody wants that. Now we know why injection is a common practice for dependency management. A mid-level developer understands clean coding and uses it in their own code, and a senior developer can get other people go along with clean coding practices.

In addition to the why of certain programming practices, there are processes or business decisions that it is helpful to understand the reasoning behind. For example, understanding the product vision. Who is the target audience for a particular feature? Are we trying to expand our product to new customers, or retain existing customers? When you know what lies behind the decisions that are handed down to you, you are able to make sense of the priorities of the business.

Sarah’s point about being senior is that a senior developer understands the why and is able to persuade others. To put it another way, it involves leadership. It’s not enough to have the right idea, you have to be able to motivate others to go along with you. It’s not enough to have the technical skills to write code. If you want to stand out as a senior developer, you need the soft skills to work with others and persuade them.

Taking the initiative

I came across an article by Vaggelis Giannikas about the 3 stages of being a Ph.D. student. Each stage involves taking more initiative and responsibility, and they lend themselves to comparison with what it means to be a mature software developer. Here are the 3 stages, reworded slightly for the non-academic world:

  1. I expect my boss to tell me what to do.
  2. I do my own research on the different options and go to my boss for advice on which one to pursue.
  3. I decide what to do and persuade my boss if s/he has any doubts.

Adapted from: XRDS Vol. 21, No. 3, Spring 2015, “The PH.D. Journey: Tips from somebody who managed to defend his thesis”

Growing as a software developer means moving from stage 1 to stage 2 to stage 3. In each stage, the software developer takes more initiative and also bears more responsibility for the outcome.

For example, in stage 1, a junior developer expects his boss to tell him what bugs to work on, and might throw in a few small features. The junior developer is mostly responsible for asking for more work, and the boss is responsible for reviewing what was done and making sure the right work is being done.

In stage 2, the boss has given a developer a larger feature, and the developer goes and researches 2 different solutions that would implement it. If the options are different technical choices, she might go to an architect for advice. If the options would have different product/user experience implications, she might go to a product manager for advice. The stage 2 developer is more proactive in getting the necessary information to make the decision.

Stage 3 represents someone who is an architect or product manager. They decide what to do and persuade the rest of the organization if they have doubts. Persuade is a great word here because it’s saying I can be a stage 3 developer without actually having the title that goes with that. In other words, even if I’m not a manager on the org chart, I can have that kind of influence on others. The stage 3 developer bases their decisions on their experience and expertise, and is responsible for impacting the organization in a positive way.

In conclusion, I liked this outline of what it means to grow as a Ph.D. student because it can be applied to becoming a mature software developer. As I grow in my ability to write code, I want to grow in my ability of seeking advice, making decisions, and persuading others.

How to make the most of a manager 1—1

The weekly manager one on one (1v1, 1:1, 1—1, choose your own punctuation) is a staple for office workers in contemporary corporate culture. Whether it’s weekly, every other week, or once a month, you’ll meet with your manager and have no idea what to say. At least, I didn’t know what to talk about.

When I started my career I had a few wrong assumptions about the weekly manager meeting. First, I assumed that the manager meeting should only happen when my manager sent me a calendar invitation. I ran into a situation where my weekly meeting suddenly disappeared off my calendar, and I assumed that this was an intentional cancellation. Three weeks later, I finally asked my manager about it, and he apologized for the lapse; he had not renewed the calendar invitation. I learned that if I had spoken up sooner, the problem would have been fixed right away.

Second, I assumed that the meeting had a specific agenda or desired outcome every week. I was a little frustrated about how open ended it was. My manager straightened me out, saying that often the agenda is just “let’s catch up.” I learned that this can still be valuable, just as a way of building a rapport and a relationship with my manager.

More recently I have come to realize that I can control the agenda in these meetings. If I plan ahead a little, I can think about what I want to talk about. There are a few areas that I’ve found valuable to bring up.

Managers are busy. They have other meetings, get hundreds of emails a day, and generally can’t keep track of everything going on around them. I found my manager one on one more valuable when I viewed it as an opportunity to make my manager aware of how I add value. I can help them by talking about the following:

  • Something I did successfully this past week
  • Talk about a time I helped someone with my expertise
  • Talk about how I’m completing my work on time, or if I’m my work is pushing beyond the estimate, why this is the case.
  • Talk about any advice I received, or any decisions I made.

Generating this kind of awareness or visibility can feel like self-promotion. However, I like to think of it as helping my manager be aware of the value I’m adding to the company. From a manager’s point of view, would you rather have to go pester each person and figure out what their doing? Or would you rather have them come to you and proactively give updates on how they’re kicking ass.

Another idea for the weekly manager meeting is to have a conversation. It’s a time slot in my week when I are not expected to be “heads down” coding. Instead of focusing on the quantitative, I can focus on the qualitative. I got this idea from the Hanselminutes episode “Speak up and present with confidence.

In this same vein, it is a chance to make sure I’m on the same page regarding any recent changes to projects I’m are working on. Was there an announcement that impacts my priorities? Did the process change? I can use the weekly meeting as an opportunity to make sure that I understand what is expected of me.

Hopefully these ideas help you like they helped me. Think of it this way: you’ll have that 30 minute time slot on your calendar regardless; why not make the most of it?

Careers for computer science students

I have often described to people the difference between computer science and information services (IS) majors. Both are offered at St. Cloud State University (SCSU), but they have much different purposes.

Computer science is a technical major, focused on data structures and algorithms. Computer science students take several math classes, as well as some science electives. IS is a business major, and it focuses on computer programming’s usefulness to business. IS majors do not have many math courses to take.

These different majors present different career options.

Computer scientist

First, there is a computer scientist. These workers “are the designers, creators, and inventors of new technology,” in other words, they do research. Most of them have a Ph.D. (In computer science, of course.)

Majoring in computer science at SCSU, I get a taste of some different topics that computer scientists study. For our undergraduate degree, we are required to take 5 upper-level electives. This semester, I am studying evolutionary computing and computer graphics. These classes present material that is fascinating to me, and we only scratch the surface of what a computer scientist would study. (For an example, see a description of evolutionary computing.)

Computer systems analysts

This summer I had an internship at a financial company. The work I did there would fall under the career of computer systems analysts. I would say a computer systems analyst could be anyone with problem solving skills, including both computer science and IS majors.

“Computer systems analysts use IT tools to help enterprises of all sizes achieve their goals. They may design and develop new computer systems by choosing and configuring hardware and software, or they may devise ways to apply existing systems’ resources to additional tasks.”

An example of a project a computer systems analyst would work on is to determine a good tool for doing version control on application software that the company maintains. The programming of the application itself falls to the computer programmers, but the configuration of the version control, as well as the build environment falls to the computer systems analysts.

Computer programmers

Then there are computer programmers. Programmers apply problem solving skills to the creation and improvement of software. Their work can be further divided into systems programming and applications programming. To be a computer programmer, you need sufficient programming experience, and a good way to get this experience is in the computer science or IS major.

Computer programmers can work in many different industries. Some industries are more technical than others. An obvious way to tell the difference is by the interview requirements. One of my fellow interns from the summer wrote this article about his interview experiences.

The financial company I worked for this summer has a very business-focused interview. Jon describes it well: “They want to know that you think logically enough to work things out so they can train you to do things their way.”

Other firms, like developer firms, have more technical interviews. These focus on coding ability. For example, they will have an interactive editing session with you and say, “write a stack.” This allows them to screen applicants who do not have sufficiently deep knowledge of programming.

Do what you enjoy

The CEO of Securian Financial Group told me, “If you’re not having fun, you’re not doing it right.” The CIO told me, “Do what you enjoy.” I’ve been spending the past few weeks thinking about what I will do after completing my undergraduate degree here at St. Cloud State University. I’ve found that many different sources of career advice focus on doing what you enjoy.

Scott Belsky has an article entitled “Finding Your Work Sweet Spot.” He describes this sweet spot as an intersection of three different factors: interests, skills, and opportunities. Interests is defined by what you love to do. “A genuine interest is not about what promises the most economic gain. On the contrary, it is a topic that trumps economic concerns because you love it so much.”

I am learning to use my interests and skills to navigate some of the many opportunities that confront me. A quote from Dan Pink on Matt Perman’s blog says that choices should be based on your values, not based on utilitarian reasons.

You can do something for instrumental reasons — because you think it’s going to lead to something else, regardless of whether you enjoy it or it’s worthwhile.

Or you can do something for fundamental reasons — because you think it’s inherently valuable, regardless of what it may or may not lead to.

If I am focusing on doing what I enjoy, I can make every decision based on fundamental reasons. I won’t always know where I am going, but I am enjoying the steps on the way. Belsky agrees, writing: “Define ‘opportunity’ as an action or experience that brings you a step closer to your genuine interest. Opportunity is less about leaps forward and more about the slow advance.”

I don’t know where I’m going, but I know where I am. There is no master plan, other than pursuing what I enjoy. A quote from Peter Drucker supports this:

Successful careers are not planned.

They develop when people are prepared for opportunities because they know their strengths, their method of work, and their values. Knowing where one belongs can transform an ordinary person — hardworking and competent but otherwise mediocre — into an outstanding performer.

(The quote is from a PDF entitled Managing Oneself.)

I think to be prepared for opportunities entails

  • finding opportunities around you (networking)
  • choosing to engage those opportunities or not
  • engaging opportunities for fundamental reasons