Tag Archives: professional development

We’ve all been there before: the boss approaches and asks you to do something that seems useless. You don’t ask questions. You just do it because they’re the boss, and that’s what they asked you to do.

Ugh. Don’t you see? Everybody loses when this happens! You’re doing something you perceive as useless, so you probably feel like you’re time is being wasted. You’re also probably not putting forth your best effort since you’re doing something you think is useless. Plus, you don’t understand the reason you’re doing it, so there’s a good chance you might overlook something that’s relevant to the actual goal. So even if you’re trying your best, you might not be as effective as you could be. Maybe there’s a better way to accomplish the goal than what you’re being asked to do, but how can you know without having any awareness of said goal?

I see this all the time, and it drives me CRAZY. It’s sad, too, because the solution is so simple: ask questions. Don’t do something without understanding why you’re doing it. The worst reason you can have for doing something is because somebody told you to do it. The next worst reason is that it’s what you’ve always done. If you’ve been given an assignment, and you don’t understand why you’re doing it, don’t just do it: ask some damn questions! You’re smart. You have ideas. If you understand the problem you might be able to come up with some smart ideas about how to solve it. (And if you can’t, at least you’ll understand why you’re doing that dumb thing you’re doing.)

You might be able to do an okay job by just doing what you’re asked to do without knowing why you’re doing it. You’ll probably do a better job if you know what’s trying to be accomplished, but you’ll do your best work if you can somehow find a way actually care about the problem. Mindlessly doing what your told is a fantastic way to be mediocre and not have a satisfying career. Being engaged plays an important role in both performance and satisfaction. You must understand a problem in order to care about it, and only when you care will you become truly engaged–unlocking your full potential, producing your best work, and feeling maximum satisfaction for what you’ve accomplished.

Like this:

This is a typical be-a-good-person-and-people-will-like-you article, but it’s good to remind ourselves of that from time to time. The concepts presented in the article that I feel are most important are transparency, adaptability, and gratefulness.

Transparency is a great leadership quality because it earns trust over time. I hate playing games. It doesn’t get anybody anywhere. If you told me you were going to start working on a project but got distracted, don’t tell me that it’s moving along just fine. Tell me you got distracted and haven’t started, but also tell me when you’ll be starting it and what will be the impact on the project timeline. Being transparent also drives customer satisfaction because it helps set and adjust expectations.

I presume the importance of adaptability transcends industry–hence its inclusion in the list–but it’s incredibly important for software development. In my experience, it’s pretty rare to have a project that goes 100% as planned. Next to never. And I’m talking about “next” being on the other side of never, not the side where it might actually happen. Understanding when to deviate from the plan is key. It might be to overcome a challenge: “We thought we could do X, but that’s not going to work. Let’s do Y instead.” It’s not always a problem that makes adapting advisable, though; it could be an unforeseen improvement: “We planned on doing X, but it makes more sense for the users if we do Y.”

And, finally, gratefulness. My least favorite type of co-worker is the ungrateful leech. You never hear from them until they need something. Then, you go out of your way to help them out–because you’re awesome and that’s how you roll–and you’re lucky to get an email that says, “Thanks.” When those guys come around looking for help, I don’t like to give it to them. On the other hand, you’ve got people who genuinely appreciate what you’ve done. They offer to buy you lunch or a drink. Gratefulness goes a long way, even if it’s just saying, “Seriously–thanks. You really helped.” When those guys need help, I’m happy to drop what I’m doing to give it to them. It’s not because I hope to get free stuff, it’s because I know my effort will be appreciated. As a leader, you’re playing the role of the guy who needs stuff in these scenarios. Do you want to be the guy that people do things for because they have to or because they want to?

Share this:

Like this:

Innovation is the backbone of any software development effort. If you aren’t doing something new, what’s the point? Without new ideas, you’ll never be first, you’ll never have something that your competitors don’t, and you will never be the best.

I think most people would agree with these statements when talking about a software company or product, but I’m actually talking about developers. You–the developer–need to constantly explore new ideas and learn new skills. Doing things you’ve always done the way you’ve always done them will likely never result in anything more than marginally better than what you have now. (Hey, more = better, right?) In other words, you will need to do new things in new ways in order to produce something significantly better than what you have now.

This is where things get a little less straightforward. How do you learn to do things you haven’t done in ways you haven’t done them before? In my opinion, it’s all about exploration and experimentation. When I read an article about a new tool or language feature, I’ll spend some time playing around with it. I don’t necessarily have a use in mind; I just want to see what it’s about. The result over time is that I have a whole host of things I’ve messed around with that are implementation-detail candidates on future projects. Additionally, when discussing new projects, I can say things like, “This is useful, but it would be really cool if we added X. Here’s how we can do that.”

We can all agree that innovation is essential, and it’s important for developers to spend time learning and exploring to help with the innovating. There are only so many hours in the day, though, and you’ve probably got other, more important things to work on. You’d love to spend time trying new things, but your boss isn’t going let you have free time to do that. After all, there’s money to be made! So what can you do?

I work for a somewhat old-school software company. The senior management overseeing development isn’t likely to institute 20% time any time soon. They aren’t going to designate a percentage of hours as play time, but that doesn’t mean that creativity is forbidden or frowned upon. It just means you have to find the time yourself. I’d venture to say that most software developers are salaried employees obligated to 40 hours per week but expected to work more. What if you spend just one hour each day learning something new? You’ll probably still be giving 40+ hours of effort to the “actual work,” but you’ll also be learning new things that interest you. Fast math shows us that 5 hours represents 11% of a 45-hour week so, by taking 1 hour each day you effectively create “10% time” for yourself. If one hour is too much time for you, take 30 minutes, or do it every other day. Take the time and stick it on the end of your lunch hour if you need a bigger block.

By allocating “you time” and spending it, you’re going to grow professionally, and that benefits both you and your employer. You’ll be better equipped to tackle complex problems in the future, and you’ll have fresh ideas for how to solve old problems. You’ll also have increased job satisfaction because you get to work on things that interest you in addition to your regular assignments. I believe it’s a true win-win scenario. So stop worrying about the hours you’re “given,” and go learn something!

Share this:

Like this:

Last week, the Wall Street Journal posted an article titled “Your Employee Is an Online Celebrity. Now What Do You Do?” The article is about the pros and cons of “co-branded employees:” employees that actively build and maintain their own personal brand outside of work. The goal of the article is to shed light on this type of employee and present some of the potential advantages and disadvantages.

The article begins with the following statement: “meet your newest management headache: the co-branded employee.”

That’s a pretty harsh introduction, but the rest of the article isn’t quite so negative. It’s actually part cautionary and part risk assessment. Several valid concerns are brought forth, such as How much time during the workday should be allocated or permitted? andWho owns the content? There’s also a “balance sheet” that compares several advantages and disadvantages.

Advantages:

Prestige – The company can claim the top-ranked employee as their own

Leads – By engaging publicly, the employee is potentially attracting new customers

Free media – A large following can equate to free or inexpensive publicity for the company

Recruitment – The employee will attract other, aspiring minds

Disadvantages:

Prima donnas – Popularity can lead to inflated egos and expectations

Distraction – The employee may dedicate a wrongly proportional amount of time to their extra-curricular activity

Leaks – Internal details may be deliberately or accidentally become “less internal”

Resentment – The employee’s popularity or reputation could negatively affect the team

These potential risks and rewards are part of a short list that could clearly be much longer. I started blogging to track things that I’ve learned and figured out, and it’s evolved into a hobby that doubles as a profession-growth mechanism.

Does it take time out of my day? Sure. A lot of things that I learn and write about are directly related to what I’m doing at work. There’s probably an argument to be made that tasks take me longer to complete because of my blogging. After all, I’d be done sooner if I didn’t have to scrub out customer-related info and write several paragraphs about why I was doing something and how I ultimately accomplished it.

The flip-side to that is that the quality of my solutions is improved by the additional diligence that comes along with my desire to write. I don’t stop when it works. I go deeper; I want to understand why it works, what’s necessary, and what’s not. Then, I take all of that information, condense and simplify it into a blog post. That post becomes my own, searchable repository of lessons learned. If somebody on my team is faced with a similar task, I can send ’em a link. They get an abbreviated version of the journey with a (hopefully) clean, concise solution.

I can only speak in terms of my own experience, but I’d certainly argue that activities like this are a win-win. My online presence, and the desire to grow it, result in an expansion of my horizons. I get personal satisfaction from learning and exploring new topics. The knowledge gained through these exercises allows me to think outside the box when solutions are needed. I’m more well-rounded because of it, and I’m more capable of supporting and providing guidance to my team on solutions old and new, alike.

Share this:

Like this:

I’m a drawer. (One who draws, not to be confused with one in a dresser.) Three sentences into any explanation, I start looking around for a whiteboard. I don’t know what I want or am going to draw, I just know that I need to do it.

Sure, I like changing databases into monsters, but that’s not the only reason I draw pictures to supplement many of my discussions. This article at Inc does a good job of identifying several advantages of visual explanations. Here’s the summarized list:

Out of sight is literally out of mind

Visuals allow the brain to take shortcuts

Brains like the familiar

Making hard stuff friendly improves communications

The last point is really the most important for me. If I’m describing a complex system to a peer, it takes a lot of words. It’s really easy to lose track of the pieces. Creating a quick doodle does a better job, and it lets the audience revisit the parts they may not understand by continuously examining the picture. It’s also essential as you communicate ideas to folks at different stages of the Dreyfus model–both higher and lower. A customer might not understand what it means to serialize an object to XML and send it via a socket connection, but they’ll understand what a box labeled “data” with an arrow means.

I like the first point that was made, too: out of sight is literally out of mind. If you diagram the entire system before talking about a change, it’s less likely that you’ll forget about a piece of it when considering the implications of the change. On a note unrelated to visuals, this is also important to keep in mind in any meeting that ends with actionable items. Make sure to document who’s responsible to do what. The verbal agreement is “out of sight” and, therefore, at risk to become “out of mind.”

Have you ever sat through a PowerPoint presentation where each slide has 100 words? It’s not good. You spend more time reading words than listening to the speaker. Even worse is when the speaker goes faster than you can read. You get 3/4 of the way through a slide without hearing a word from the speaker only to be cutoff as they move to the next slide. I really like the example of Jobs as a compelling reason to use visuals as shortcuts. If you show me a slide with a solid block of text, I’m far less likely to retain your message than if you were to show me a slide with a single word, phrase, or image. Keep the message in your slides clear and direct, and speak about the rest.

Share this:

Like this:

Inc.com has an article by Jeff Haden from earlier this week titled “Best Interview Technique You Never Use” that I thought offered some good advice. The article suggests that you’ll get more information and insight by simply pausing for a 5-count before moving on to the next question. Just as it is natural for you, the interviewer, to want to ask another question to kill the silence, the candidate is likely to do the same by elaborating on their response.

I know I’m definitely guilty of doing the opposite, firing question after question at a candidate immediately once I think they’ve finished their response. My rapid-fire technique results in very fast interviews that only scratch the surface. I’m relatively new to interviewing at this stage in my career, and I don’t think I’ve become particularly adept at it yet. Perhaps part of the problem is that I haven’t been listening slowly enough.

This is definitely a tip that I’m going to keep in mind as I work to become a more effective interviewer.

Share this:

Like this:

If you want to have a successful career in software development, I have one very good piece of advice to offer: put your reputation above all else. I imagine this advice translates to other industries, but it’s certainly true in the world of software development. Here are some tips that you can use to help build and maintain a strong reputation as a developer.

Think like a user

Thinking like a user is a wonderful ability for a developer. When you add a piece of functionality, think to yourself, “How would I like this as a user?” Would you want to type in a file path? Probably not. You’d rather have some sort of browse capability that let’s you click through directories to find a file. Would you like browsing to an install directory, opening a config file, and editing XML to change a setting? Doubtful. You want to click a button or pick a menu option in the application to change settings.

I like to say that I “create software that works like software should,” and it’s all about thinking like a user. Users don’t want complicated, unintuitive solutions. They want something that is easy to use, does what it’s supposed to, and looks good. Think like a user, and create great products. Nothing will produce a better reputation than consistently producing great products!

Have higher standards than everybody else

Let’s say you–a customer–have low standards, and I–a developer–have “normal” standards. I give you an application that meets my normal standards. It has some minor bugs, but it’s generally functional. Since you have low standards, you’re probably happy with it, and we have good product satisfaction.

Now let’s say you have higher standards than me. I give you my same, normal-quality application. The previous flaws are now less acceptable, and satisfaction decreases. We get into a situation where satisfaction is mediocre. Easy-to-please customers like it, hard-to-please customers don’t.

If you hold yourself to a higher standard than everybody else, though, it’s likely that you’ll delight users more often than not. When a solution isn’t up to snuff, you need the courage and discipline to put the brakes on. Make sure it meets your standards before handing it off to others, and that brings me to my next point…

Ask for more time

Never, NEVER say development is done before you believe it is. I’ve had discussions with co-workers over the years that go like this: “Managers only care about closing projects. They don’t care about quality or doing it right.” It’s definitely true that managers care about closing projects, and rightfully so–you should, too! I don’t believe they want it happen at the expense of quality, though. If they do, they’re a bad manager, and you need to figure out how to make sure their bad managing doesn’t bring you down. I’d venture to say that 99.99% of managers and customers in the world will prefer a complete/good solution 2 weeks late over a partial/bad one delivered on time. So, when you need more time, you should ask for it.

There are some tricks to asking for more time, though. First and foremost, try to ask before you’ve actually run out of time. Everybody will be annoyed with you if they’re expecting a product on Monday and you tell them on Friday that it won’t be done. On the other hand, if you come to them two weeks before the deadline to request an extra week, it will likely be more well-received. And so comes the next trick: know how much time you need. You won’t be doing yourself favors by extending the deadline, and then extending it again, and then again. When you know you’re not going to finish on time, evaluate the work that needs to be done and estimate how much effort will be required. This will help in your explanation of why you need more time while simultaneously helping to ensure you ask for a sufficient amount of time.

Have integrity

I’m telling you that your reputation is the most important thing you have, but you should never try to protect or improve it by sacrificing honesty or integrity. If you make a mistake, own up to it, and grow from it. In fact, the bigger the mistake, the more important this becomes. Let’s say you introduce a bug that cripples your customers. Clearly, it would be better to take action, letting everybody know about the critical issue and working to resolve it, rather than letting it be discovered on its own and inevitably traced back to you! Acknowledge that you made a mistake, and do whatever you can to help make it right.

Being open and honest will earn you the respect of your peers, your managers, and your customers. Treat others as you wish to be treated. When I’m asked a question, I answer to the best of my ability, providing accurate information–good or bad–along with relevant supporting details. I respond that way because that’s the type of response I hope to get when I ask a question. If you don’t provide accurate information, you’ll soon find that people don’t care what you have to say.

Share this:

Like this:

I stumbled upon an interesting article this morning about the thing the best (and worst) programmers all have in common: their work environments. The study was conducted by giving an assignment to over 600 developers across 92 different companies. Each participant had a partner from the same organization, but they were not allowed to speak to each other about their assignments.

Here’s a summary of the results:

The best participants outperformed the worst by a ratio of 10:1

The top performers were 2.5 times better than the median

Experience, salary, and time spent completing the assignment had little correlation to outcome

Programmers who turned in “zero-defect” work took slightly less time than those who made mistakes

The interesting part of the study is that “programmers from the same companies performed at more or less the same level, even though they hadn’t worked together.” I found that to be fascinating. It makes sense, though. Essentially, developers are a product of their environment. A low-performing environment will produce low-performing developers. Good developers on bad teams will either improve their team or move on to a better team. Bad developers on good teams will not be tolerated and will be bumped (fired/transferred) to a lower-performing team that’s more tolerant of or suited to their lesser ability.

The message I got out of this is to not accept being a member of a poor performing team, or you fill find that you’ve become a poor performing developer. Steps must be taken to improve the team. This can really be done in one of two ways: help the team overcome its shortcomings or find a new team.

Share this:

Like this:

I thought it was somewhat self-serving when my manager sent out an email to the team with a link to an article at Forbes about being a great follower, but it was actually a very good read. The article, titled “The 11 Leadership Secrets You’ve Never Heard About,” makes the point that the leaders among us are simply the best followers, and it reminds us that our leaders have bosses and are followers in their own right. The list of leadership secrets is about being a great follower, and it’s an excellent list.

There were a few items that really spoke to me, and it’s true: these are the things the leaders of tomorrow are doing today.

Great Followers are Great Communicators

I loved this one. (Not surprising, as somebody who clearly values communication!) More specifically, I love the idea of proactively providing relevant information. If I see something and dig into it, totaling numbers and gathering statistics, I’m going to send an email with that information displayed several different ways. Here’s a table. Here’s a graph. Here’s a 3D graph! When somebody else on the team sends out an email with data they’ve collected in a cool graph, I’m absolutely delighted.

And, to the point of the article, I’ve never received an email of this nature from somebody that I didn’t consider a leader on the team.

Great Followers are Goal Driven

There’s a lot of material out there about being successful by setting goals for yourself and being goal-oriented. Earlier in my career, I wanted to embrace this and set goals for myself, but I felt like I was a really bad goal-setter. I simply didn’t know what kinds of goals to set for myself! I like the text in the article on this item because it doesn’t just say, “set goals for yourself.” Instead, it talks about working forward versus working backward.

Great followers reason backwards: they use future goals to prioritize today’s “activity.” Poor followers reason forward: They react to their in-box and email in the forlorn hope that just staying busy will magically produce results somewhere “down the road.”

Well put! The amount of work will always be unending. If you focus solely on fighting it down, you’ll probably be stuck in the same role doing the same thing for longer than you care for. Conversely, if you can identify ways to improve the processes of today down the road, you can steer your activities in the right direction. Once you achieve the goal, you can get on to the next thing!

Great Followers Show Don’t Tell

This is another one that’s near and dear to my heart. I get pulled into a lot of what-do-you-think, consultation-type meetings. In those meetings, I’ll throw out ideas that seem like they should work. Energized by a potentially great idea, I often start putting together a proof-of-concept as soon as I get back to my desk. It’s exciting to me to send an email with a fully-functional example of what I suggested might work an hour before. Unfortunately, based on the amount of emails like this that I receive, I don’t think many people are doing this. Additionally, showing up to a meeting where it’s clear that you’ve put effort into your preparation will impress the room. Take time to prepare a PowerPoint presentation or print handouts on the topic you’re presenting or might be consulted on. You’ll be better prepared, and it’ll be noticed by peers and leadership, alike.

Great Followers Offer Solutions

This one’s definitely a favorite. Do you have a problem? What can you do about it? What are the advantages and disadvantages of your options? This is decision-maker training. When you’re new at it, evaluate the situation and bring solutions along with your problems to your team leads and managers. You may not come up with the best option, but that’s a learning opportunity. Over time, you’ll learn how to identify the best options, making you a leader capable of finding the best options to other people’s problems: you’ll be down with OPP.

Great Followers are Loyal

I’ll comment on just one more item from the list, and that’s loyalty. The article points out that a great follower will go out of their way to make their boss look good, which really couldn’t be more true. (I was once again chuckling at the self-serving nature of this statement in the article sent from my boss…) It’s true though; a great follower will take pride in making their team great. When it’s time to look for emerging leaders, the best teams are probably a good place to start.

The rest of the list is very good, too, and these were just my favorites. Check out the article and think about how you can improve as a follower. Focus on being a great follower, and you’ll naturally evolve into a leader.

Share this:

Like this:

I just finished reading an article at Inc.com: 10 Habits of Remarkably Charismatic People. I like reading these types of articles because they help me find new ways to be a little better, or they give me a little pat on the back when they suggests habits or behaviors I already do. Like most articles of this nature, the list wasn’t exactly earth-shattering. Here’s the abbreviated version:

Listen more than you talk.

Listen to everybody.

Put distractions away.

Give before you receive, and expect to receive nothing.

Don’t act self-important.

Realize that others are more important.

Shine the spotlight on others.

Choose your words. (Choose to be positive.)

Don’t discuss the failings of others.

Readily admit your failings.

What I like about this list is not that it illuminates a path to +1 charisma but that it reminds us to be good people. The article could have easily been titled “10 Tips For Being a Good Human” or “10 Ways to Make People Not Hate You At the Grocery Store.” (Seriously–apply these at the grocery store, people.) But you know what’s more fun? 10 Habits of Remarkably Uncharismatic People:

Talk all the time. If it’s worth saying, you’re probably talking about it.

Only listen to people from whom you have something to gain. Otherwise, what’s the point?

Back to the point, the 5-second version of the article goes something like this: be a {humble, respectful, positive, gracious, transparent, good} person, and people will like you more. When you put it like that, it’s a pretty obvious message. Nonetheless, it would go a long way if everybody were to embrace this list and focus on being a little more charismatic in their everyday lives. More specifically, at the grocery store. And at restaurants.

Share this:

Like this:

Posts navigation

Hi, I’m Adam. This is my blog.

I started this blog as a personal searchable repository of things I've learned and figured out. It evolved into a mechanism to facilitate personal growth, and now it's turned into a bit of a hobby. I enjoy writing about software development, my professional life, and related topics.

I love to hear from readers, so please feel encouraged to leave comments on anything you read here.

Follow Blog

Enter your email address to follow this blog and receive notifications of new posts by email.