How do I Set My Goals?

I spent some time today working with my boss to define my goals for the year. I'm glad I work in a place where I get to help define my goals, and don't just have a task load handed down to me from the nether where I'm not even sure where a task originated.  One of the great benefits of having goals is knowing how to do my absolute best to exceed all expectations of my performance. Another benefit of having goals is to have something to measure myself against. And, goals also help me as a person better understand if my boss' expectations of my output match my expectations of what I'm capable of as a worker.

When I was taking a course in operating systems (and at the same time taking a course in operations management...) it occurred to me that the algorithms used for processor scheduling, specifically determining which process/thread gets processor priority at a given moment, isn't very different from operational management.  However, instead of working on an application process, usually operational management focuses on a project or output of a product.

The operating system has "goals" for its processor.  It knows which applications get more priority based on the importance of the process for the user, and for maintaining system operations. In the same regard, goals as a developer give us the direction that we need to focus our attention.

I can't speak for every developer out there, but for many of the developers I've worked with, solving one problem can lead to research and implementation that may not actually solve the immediate problem at hand, or even really have much of a relationship to the original problem being solved.  I, myself, have regularly had programming problems/algorithms invite my brain to start contemplating P versus NP Problem, but I have the added benefit of goals to look at and remember that solving P versus NP has 2 issues:

1. It's an impractical use of my time in the current situation I am in because it doesn't really help me reach the goals my boss and I have set for one another
2. Theoretical thinking is great. But it's even greater if it applies to the problem I'm trying to solve

Sometimes goals are used as extrinsic motivation (I think this is a horrible idea.  So does this guy: Dan Pink: The Puzzle of Motivation) and if this starts happening, it's probably time to re-evaluate the goals system, and also potentially your current employment situation.  If, however, the goals you define closely mirror what you're intrinsically motivated to excel at anyway, goals give us a clear picture of what we "Should" and "Shouldn't" be working on. For me, that's a clear removal of cognitive dissonance, and something that I really appreciate having.

How Do I Stay Connected?

Something interesting happens when you start professionally networking.  People start to notice you. The number of connections that I have on LinkedIn currently exceeds 400. These are all people that I know personally, or have in one fashion or another interacted with professionally. This isn't the same thing as a Facebook friendship. I don't currently use Facebook (which is a long and rather non-relevant story here) and even when I did, I had less than 400 friends. Yet, each one of the interactions I have on LinkedIn has some kind of relevance me professionally.

Something interesting happens when you start having a wide professional network. People start to notice you. I have recruiters contacting me routinely with new potential positions. Most of them are just desperate and trying to meet a head count for a nameless entity that they may or may not really care all that much about.  Some of them don't even really speak fluent English.  I even had one ask me if I was fluent in "C Pound". <phone click>

However, if you can tolerate a little bit of "recruiting noise" networking is one of the best ways to find employment - whether through a conventional "career" or by acting as a consultant.  When you put your experience and your knowledge on the internet for everyone to see, you expose yourself to potentially amazing things. My current position is absolutely no exception to this rule. Every job I've held has been "better" than the last one, whether through an internal move or by changing to a different company.  Because of my family responsibilities and the relatively low need for contract work in the market I live in, consulting hasn't really been a viable option for me to consider.   Plus, I really do love my current job.

However, with the wide berth you get having a global profile on the internet, companies from all over the country/world know about you. And there's a talent shortage for good engineers right now. But, the best companies want to ensure they get the right people. And they're going to dedicate resources to researching finding the right people for their organization.

Amazon has contacted me twice about starting a position with them. Unfortunately, moving to Washington isn't really in the cards for me. But it's exciting to me that large companies like them take notice of my capabilities. And it was easy to do. LinkedIn is really a powerful tool that no professional should ignore.

There's other kinds of professional networking available, too. Believe it or not, Twitter is a great resource for professional networking.  As long as you use it properly.  There's also this archaic medium called face-to-face conversation that works pretty well too.

Most of the engineers I know either consider themselves socially inept, or just really don't care about the socialization aspects of their careers.  A small core group of guys that I know really well all stay in touch via Google Hangouts.  I think this kind of communication is critical.  A few of them even keep me honest on this blog, making sure I'm not screwing up spelling, grammar, and other important things. And they're giving me content feedback, too.

Your professional network may just be one of the most important tools you can rely on for growing your career into the thing you want it to be. If you ignore it, you'll likely be stuck just applying blindly for jobs that you may or may not even want.  If you capitalize on it, I really don't feel like there's a limit to where it can take you.  What do you think?

Hey, This Topic is In a Book!

I've started reading this book today a little bit:

http://www.manning.com/sonmez/

Treating your coding career as a business seems a central topic that weaves in and out throughout the small parts of it I've read so far. Give it a go, it was recommended to me by a higher up at my job.

Can Meetings Not Suck?

If someone could figure out a four letter word for meeting, most of the engineers I know would probably choose to use it. At my current employer we have a term that I would imagine gets used lots of places... "meetnapping."

So, as engineers we have to effectively manage the time we spend in the office so that when we do attend meetings, it's providing as much or more value to our organization than other coding or design work we can concentrate on.

One way to help ensure you're not the victim of a meetnapping is to insist on an agenda being delivered to you prior to your attendance at a meeting.  The agenda should have enough information in it - including the intended purpose of the meeting - for you to decide whether or not you could provide value to the meeting. It also works the other way around, a proper agenda should also inform you if attending the meeting will provide you with any insights you need to work on your current task list.

The same courtesy should be afforded to others that you wish to schedule a meeting with. If the people you invite to a meeting can't quickly understand the purpose of the meeting you have invited them to through the title, then the next best option is to provide a brief and well organized agenda. Here's the tricky part. Stick to the agenda you laid out, because once you've provided an agenda you've created a "meeting interface" - no fair implementing additional methods that you didn't specify in your interface to begin with.  And especially no fair (heck - it's a compiler error) not implementing the methods you specified in your contract to begin with. Think of your agenda like a coding interface, and suddenly it becomes much more clear how it's useful (at least in my mind).

The best chance you have in sticking to an agenda is to bring a wingman with you. As the organizer of a meeting, it's fairly easy to get distracted into other side topics that you may feel are related to the topic at hand, but that may not provide immediate value to the other attendees of the meeting.  This is where it helps to have someone come with you that you can trust to keep you on track. Make sure this person has a copy of the agenda. And make sure you trust them to interrupt you if you stray from it or start taking too long on a given subject.

While these strategies won't eliminate meetings from your schedule altogether, it can help you more efficiently decide which meetings to attend and also give you a good reason to tell your boss that a certain meeting is probably outside the scope of your responsibility.

Another good rule of thumb that most managers and healthy teams will usually willingly stick to is to schedule meetings surrounding natural breaking points in the day.  Have your meetings not long after you get in to the office (not my favorite, but it works for some people), right before lunch, right after lunch, or at the end of the day. That way the "manager hours" that require meetings and the "engineer hours" that work best when you get uninterrupted work time have a better likelihood  of positively interacting with one another. As another rule of thumb - if you want to attend only one meeting per week, schedule it at 3PM on Tuesday. Though I can't cite them here, I've read several studies that suggest this is the absolutely perfect time for having a meeting. (I realize this is pretty ludicrous, I have 4 meetings on my calendar for tomorrow already.)

What Is This Blog All About, Anyway?

It's become somewhat apparent to me that many software engineers keep blogs going about the interesting and informative topics, ideas, technologies, platforms, and general day-to-day that radiates through their lives. There's all kinds of amazing blogs out there teaching the cutting edge, or extrapolating on dealing with legacy nightmares, or doing agile development, and a plethora of other developer related topics that run the gamut. One of the things that I don't see as much of, though - money.

Almost all of the software engineers/programmers I know write software for the love of writing software. We spend time at home reading about technology, experimenting with technology, and in general, just being technologically engaged people. Because of this, another trend I've noticed is that most of the programmers I know don't really treat their skill set as a business model.  I'm sure there's other fields where people love what they do but don't spend all day thinking in business terms - but software engineering is the one I'm personally closest to.  Sure, we all have resumes and watch for the best jobs out there. But something that I see happening less often is taking responsibility for professional growth without just job jumping. I'm guilty of job jumping on occasion too - but we'll get to that in some other post.  A range of topics come to mind, and this list is by no means exhaustive:

• Strategies for asking for a raise (especially when you're certain you deserve it)
• Strategies for earning a promotion
• Professional networking
• And Professional groups / organizations
• Having a professional growth plan
• What is a key performance indicator (KPI) and why does it matter for your salary?  More specifically, how to prove that you need to have some impact on at least one KPI? And, that you need to be recognized when that KPI is impacted positively.
• Engineering advocacy in product ownership
• Continuous improvement where it counts (how to talk ROI with your boss)
• This relates to KPI, but KPI is what you should measure if you can as a part of the business unit. Talking ROI is about how to prove your value. Sometimes it's difficult to use business KPI to prove ROI - since ROI can be qualitative in nature, where KPI is almost always able end up on a graph. And, sometimes it's really hard to prove that positive changes in KPI are directly because of something you did.
• Why you might be a great engineer (or other professional) but a terrible boss (don't get insulted, it happens to most engineers/professionals I know)
• Entrepreneurial development mindset
• Side Projects

I don't know if anyone will end up reading this, but I hope that some of what I write ends up informative and useful to others who get a little bit lost in the "politics of money" surrounding their jobs. Obviously, the first and most important thing is love of the game. But, once you love the game - it's also important to get paid appropriately for it.