How to stay motivated when it feels that senior colleagues aren't?

Question

I passed out of my college with a degree in computer science about 2 years back and since then I have worked in a multi-national firm which pays me decently well. I am sincerely interested in technology and in my work and I try to do everything to the best way possible and also learn the maximum out of it. I have a few colleagues who are experienced and really smart and I really enjoy and learn a lot working with them.

However, I feel the same is not true for all my colleagues. There are many others who are simply not interested in technology. When given a problem, they would choose the first available option or they would just look at an existing solution and copy-paste the same. And such colleagues are actually at positions senior to me. My firm is not strictly an IT firm and so people not being very good at technology is not uncommon.

My question is, how do I work with colleagues like those, especially when they are senior to me?

I feel bad (and also sad) when something is done in a way when I know a better way to do the same exists or when someone does something without much effort and I know that had I done the same, I would have put more effort and come up with a better solution. I can go on with more examples but hopefully I have explained the general situation. I can't correct everyone/everything, I am not the smartest person either but at times you know that things are just not as good as they should be.

How do I make my work experience more enjoyable with such colleagues? Also, how do I keep myself continuously motivated when working in such an environment?

_{PS: While I appreciate all the responses, I am surprised to see so many people advocating sub-standard work as long as you "get it done". Is that what is expected of me as well.}

_{Also, I didn't want this to be a discussion on best ways of writing code which some of this has turned into.}

Answer 1

I have been in your situation more times than I care to remember. I got my first IT-related job in 1984, and I've been going ever since. In many jobs I've held, I've worked with people who were more interested in "getting it done" with no thought to the future impact or overall design approach. I've worked with people who were simply content with doing as little as possible and enjoyed getting paid at a level which reflected the market, rather than their contribution. I've also worked with people who were passionate about the work they do, and wanted to provide quality service and products. I've worked with people who may have been socially challenged, but their brilliance reflected in their work ethic and sense of ownership of their tasks and assignments.

In all of the situations I have mentioned, the common thread is that I was able to learn something from all of them, no matter how seemingly unimportant or philosophy-changing it was at the time. Your coworkers are going to be driven by different objectives. Some simply need to provide themselves and/or their family with security. Some need the money commanded by IT professionals to feed their material needs and desire for status. Some would do the work for half of what they are getting, just for the personal satisfaction of doing a good job. In any case, your best approach when dealing with your coworkers may to be to simply accept that the people around may not be guided by the same drives as you. It doesn't make them less worthy of your respect and support, because they are your teammates.

That being said, just as you should accept them for what you perceive to be their shortcomings, they should also accept you for what they may believe to be your shortcomings. You have to be true to yourself and what drives you. If you want things to be a certain way on your projects, you should be able to do whatever you believe to be best. You can't expect them to adopt your approach, but you can make suggestions. If they choose not to implement your ideas, so be it. Don't feel rejected or slighted, because, as long as you are following the approach that suits you, your work will get done. Over time, you may acquire some converts and you may see some implementation strategies they are using that you wish to adopt. Everyone can learn from each other. The challenge is the removal of the assumption that because this person is not doing it the way I am doing it, he/she is doing it the wrong way.

Answer 2

I think there are several things you can do to stay motivated.

1. First, realize you are not alone. Look around this forum. There are actually many questions that are similar to yours, although most are less direct. I've actually had the experience of being hired because I knew best practices, but wasn't allowed to implement best practices very much at all.
   I think that it's easy to form a world-view where you imagine your conception of excellence is important to everyone. After all, in school you are taught certain things as best practices and the bloggers you look up to take those ideas as read. But that world is invisible to many "average" developers, and even those who know about it may not feel it is as important as you do. However, simply knowing that you're not crazy, that other people encounter brick walls when they want to implement all these good things, will help you keep your sanity.
   This is not to say that you should lose your drive: don't. My completely made-up estimate is that maybe 25% of developers really have it. Eventually, you will find a place in life where the drive works for you rather than frustrating you, and when you do, it will be rewarding in a way those 75% of developers may never experience (this may or may not be financial rewards).

2. Stay positive. The very fact that you posted the question indicates that you know that there's a risk of getting mired in negative thoughts as your frustration eats away at you. If you find this happening, find ways to turn your thoughts to positive things. Go for a walk or listen to some happy music while you work. Really dig into what you are doing and block out the things that others are doing that frustrate you.
   One thing that will help you stay positive is to avoid ascribing motives to others. All you know is that your frustrating coworkers don't want what you want them to want. Let them worry about why. Stop thinking even that they are unmotivated. They may be very motivated, but in ways that you don't care about.

3. Consider the issue from other perspectives. One thing my boss tells me on a frequent basis is he doesn't even care if it's faster to do things one way vs. another way. What he really wants is to have a really good idea of exactly how long something will take. If you always do something the same way, it fulfils that goal, to most people.
   Looking at the other side of things, trying a radically different approach, even if it is better practice, carries a significant risk that you might not meet deadline. From that perspective, trying approaches other than the tried and true is actually a bit unethical--you're doing something for your own mental health that may not be good for the health of the business.
   Many developers and managers do not realize that good code actually makes it possible to make more reliable estimates. However, since you are only two years out of school, consider the possibility that you may not yet be ready to write that kind of code and letting you spend the time learning it could cause the company to miss some key deadlines, even if it's great for you.

4. Work for change. Put some skin in the game, and take some of your personal time to put together a demo of the techniques that you feel should be put into place. When you make your pitch, be really careful not to say anything that sounds like a criticism of any person, and try to avoid saying "this tehcnique is bad." Instead say "I think if we did X, it would save us 30% or more of the time that we take to do task Y compared to what we're doing now." Stick to this non-critical, non-accusatory strategy even if you're asked leading questions like "But I thought we already were using best practices. Why aren't we doing this?" I followed this strategy, and I wound up getting the green light to rewrite our entire codebase.
   By doing this, you might be able to put enough of a prototype out there to demonstrate that, just because you're not the most experienced member of the team, doesn't mean you can't write solid code. And you might learn enough from this that even if you're told "no," you're better able to write that type of code in the future (at this job or another).
   You may be told "no," but people will remember that you took a stand. That may move the needle a bit, since you said not everyone is unmotivated. If you really believe this is the best way to do things, don't let it go, but be wise in how you press the issue. For example, when I came back from vacation and I was asked to make a change that I couldn't make because the site had been changed in ways that I had no way to know about, I pointed out to my boss that if the site had been under version control, I could have looked in the log and just seen what happened. But I would not have made that comment in front of other employees. These types of comments can seem snarky, so use them sparingly and only in one-on-one conversation. The odds someone will think they are snarky goes up exponentially based on the audience size.

5. Build support. Consciously cultivate your "experienced and really smart" colleagues. Go to lunch together and discuss what's bugging you (in a positive way like "I had this idea..."). If they know what you think and you know what they think, when you're in meetings it is very likely that they will naturally join their voices to yours or vice versa. In fact, you should seek out opportunities to support anyone who is doing anything like offering a best practice idea, whether you previously knew this person was interested in best practice or not.
   After you have built a good base among the likeminded developers, see if you can cultivate the ones you don't see as motivated. For one thing, they might surprise you. For another, they're less likely to out-and-out block you if you have a personal friendship.

6. Realize this job is not your life, and may not be your future. You are not stuck in this job, but while you are at it, milk it for everything you can in terms of what you can learn. Maybe they will never appreciate the fire you bring to the job. That's ok--learning how to live in a job that doesn't "get" you is a valuable skill. But once you feel that you're ready to spread your wings, if you see a better opportunity, go for it. Thinking of the job as just what's going on "right now," rather than "how it will be forever" can change your attitude a lot.

7. Give it time. I once had a boss (who was on the verge of retiring) who told me "Amy, you don't have to get so angry. Just do what you do and eventually people will start to realize you're right a lot." It takes time to build cred, and teams don't change overnight just because you point out that they should. Give your ideas time to sink in and keep plugging, and maybe in time you'll look up and realize that things have changed a lot, for the better, in less time than you were afraid of. This happened to me :).

Answer 3

I have no idea how CS degrees work where you're from, but from what I've seen, they have very little to do with the work of a software engineer. Academia is famously shielded from the real world.

The hard part is striking a balance between some untangible ideal and the "it just works" solution. Either of the extremes work, in fact - in some environments. If you're making contract end-user stuff with no prospects at maintenance, "just getting it done" is a valid philosophy. When you're writing Shuttle software, you've got a lot more time to polish.

When you're trying to change the approach of the people around you, make sure to actually be sure about the benefits. Build up the pro's and con's, estimate the costs associated with "bad solutions", and the costs associated with "proper code" - neither is free. If you're lucky, the people around you understand opportunity costs - that makes it much easier to go towards better architecture, better code. If the code takes twice as long to write, but is half as much work to maintain and extend, you want to show that that cost actually pays back at some point, with reasonable certainty.

Customer satisfaction is also a hugely important factor. If the choice is between better code and better user experience, UX always wins, and it should. Again, the biggest tipping factor is when better code leads to better UX in the future - will the impact of better code be enough to make it cheaper in the end? Good code is often an investment, not something of value out of the box; rarely will you find an opportunity when good code gives better efficiency on the original task (note that I'm talking about "bad" code produced by good programmers - if your programmers are simply bad and sloppy, you're out of luck); the payback usually comes further down the road, if at all.

People have trouble thinking about investments. Get some numbers. It can be very helpful if you can actually gather some data from the past - when you suggest some architectural or code quality change, write it down. When the time comes and your suggestion would save time or improve customer satisfaction - write it down. When you have enough, go to your managers, seniors, whoever - it's easier to argue when you've got "hard" data in your hands.

The reverse applies too. Don't assume that "better" code is automatically better. I've seen many cases where the programmers were losing way too much time working out things that didn't matter - on a test application that was only there for one scenario and thrown away, elsewhere creating an architecture that was overly complicated and in the end inhibited further development.

Perfect is rarely good. If your backlog isn't full of (minor) bugs and feature requests that you simply don't have the time and resources to fix, you're probably doing something wrong, and your competition is gaining on you.

I'm usually thinking in terms of time or money. Translating things to money helps a lot in cost-benefit calculations. This took me a bit more work, and I got some experience from it. How much would I pay for that knowledge, was it worth it? It will save me some time down the road - is it enough? What will be the cost if I don't do it that way and it will turn out to be a bad decision down the road? It's crucial to know how much time was spent fixing bugs on the original task, otherwise the perception gets extremely skewed. If something took me 4 hours, just as estimated, but then I spent 20 hours fixing the bugs, it has to be visible that my estimate was way off.

It takes a lot of pushing if you're "the only one". But it can be done, you can move to better practices, better code, better software. Just make sure that in the end, it's actually better in some measurable way.

Answer 4

When given a problem, they would choose the first available option or they would just look at an existing solution and copy-paste the same. And such colleagues are actually at positions senior to me.

........

I feel bad (and also sad) when something is done in a way when I know a better way to do the same exists

Your colleagues may be in a position senior to you because they're able to get stuff done quickly, and effectively.

When you say that a "better way" exists, are you saying that the way it was done was not elegant, not "pretty", and that you had a slicker way to accomplish the same? Or are you saying that your colleagues are putting out dangerous, un-secure code, or code that will be terribly difficult to maintain and scale?

If the first is the case, then welcome to the real world. Companies want stuff done quickly, since time is money.

If you're dealing with the second, then it sounds like you're in a terrible company with poor management. Suck it up, learn as much as you can, then move on to a better opportunity when you have the chance.