40

I have been working for a big company (8000+ employees) for almost 2 years now, and was hired just after I finished my study course.

Everyone here has to deal daily with legacy code which is often very badly designed and full of hacks. At first, I kept a low profile, trying not to criticize things too much. But the situation, as it stands, has become very difficult to live with and it seems no one is willing to improve/replace the tools we use.

To be more explicit we have:

  • An obsolete source control tool (Visual SourceSafe)
  • Plain old makefiles which only support full rebuild
  • .def files which must be maintained manually and separately for all existing architectures
  • monolithic headers files and projects with very few different files (but each has around 3000 lines of code, which sometimes takes care of very different tasks)
  • no use of the "new" languages facilities (well std::string is not that new but nobody except me uses it)

I decided, a few months ago to do something about it, by designing a new compilation environment. I could get incremental builds to work reliably, faster compilation times, better structured projects, automatic .def files generation. I even created a bridge from/to Git to/from Visual SourceSafe.

I showed my achievements to several collegues and our boss but it was like nobody cared. They were all like "Well... people are used to do it that way now. Why would we change things ?"

The changes I suggested were designed so that we could have a soft transition from the old system to the new one. Each improvement could be applied separately and safely.

I even tried to get some of my coworkers involved in the changes. But so far, no success.

Have you already faced a similar situation ? What can one do when "lead by example" doesn't work ?

ereOn
  • 2,001
  • 2
  • 18
  • 20
  • 10
    "I decided, a few months ago to do something about it, "... "I showed the result to my boss". Sounds like you got the order wrong there. –  Jan 27 '12 at 12:40
  • 3
    @ThorbjørnRavnAndersen: Not sure to get it: How am I supposed to show something I haven't done yet ? Or perhaps you meant that I should have asked before doing it ? – ereOn Jan 27 '12 at 12:56
  • 1
    you should have discussed this with your boss first. This is a non-trivial change which has long term impact. –  Jan 27 '12 at 13:05
  • @ThorbjørnRavnAndersen: Ok, now I see what you meant. I actually talked with him about it *before* but it seemd it wasn't perceived as a necessary change. I can't blame him, because no one else seems to need this change. Most of them don't know about the new techniques/principles that drives modern developments so they don't request for it. – ereOn Jan 27 '12 at 13:09
  • This is a prime example why you should do the talking _first_. –  Jan 27 '12 at 13:25
  • 21
    I've been there, and IMO, you need to get out of there, because, as the saying goes, "an idiot will always beat you -- first he'll dumb you down to his level and then beat you with his experience". If people fail to recognize the need to upgrade, that's professional stagnation, and stagnation in our field is death. You can put the things you've done on your CV and if you're good, you'll probably get a good job within a month anyway. – TC1 Jan 27 '12 at 13:34
  • @TC1: I already did job interviews and was offered a job several times. However the salary gap was so big I couldn't accept it (My girlfriend is still a student and I have to pay for both of us). I won't resign to stagnation however: I work on many open-source projects and always find some time to keep-up with the new tools/principles. I just wonder if I can "fix" my current job before throwing it away too fast. – ereOn Jan 27 '12 at 14:00
  • git to VSS, oh lord no, no wonder they don't want to change. Moving away from VSS is a very good thing, you first have to prove that it is broken. For my old company that happened when VSS started getting corrupt regularly (checkin over a WAN usually does it ;) ), then I migrated them to SVN as that is used a lot like VSS and so not so much of a culture shock. – gbjbaanb Jan 27 '12 at 14:20
  • 2
    As for stagnation, think of it like this: there's *always* something new coming up, if you don't learn it right now, it's ok, learn it later - or learn the new new thing that'll be around then. In the meantime, get your job satisfaction from delivering your products, dev shouldn't be just about playing with the dev toys but actually delivering something useful that makes a big difference to the business. – gbjbaanb Jan 27 '12 at 14:22
  • 1
    @ereOn Well then the best thing to do is coming up with hard numbers about how much time could be saved by decent tech and showing those numbers to management. I got my previous place using Maven 3 (up from v1.0.1) and Hibernate 3.5 (from v2.1) and a rather strict no-warning policy implemented. Of course for a while I was the bad guy, and some ppl still hate me there, but at least it got bearable for me. In the end I quit for the sake of my own sanity though, 'cause I couldn't get them to upgrade Java 4 to 5/6 & rewrite some catastrophic parts... – TC1 Jan 27 '12 at 14:40
  • @gbjbaanb Coming up with "something useful" is all peachy, nothing wrong with that, but if you don't more or less keep up with the new stuff, it only takes some 6-12 months 'til the only place interested in you will be your current one. A good example would be, e.g., Python & Django, which, at least in my part of the world, went from "we don't need this crap" to "omg, we'll pay you in unicorns & virgins for it" in somewhere around a year and a half. Java gets nowhere near the hype or demand already & looks like it will eventually die off here sooner or later... – TC1 Jan 27 '12 at 14:45
  • @gbjbaanb: Not sure why you seem so shocked by the "Git to VSS" thing. Sure it's not the most easy change to suggest and I mainly did it for my own sake because, as you said, VSS is very broken. I actually still got my job done, no worries. I usually do it faster, because of the improvements and design decisions I made so it buys me time to remain up-to-date regarding new techs. – ereOn Jan 27 '12 at 15:51
  • 8
    Holy cow, **8000** developers? Who do you work for, Facebook? Google? Microsoft? – Kyralessa Jan 27 '12 at 16:08
  • 5
    @Kyralessa: i don't think facebook nor google use VSS. – Jake Berger Jan 27 '12 at 16:16
  • @jberger, one would certainly hope not. But with that many developers, there are bound to be a few rogues. – Kyralessa Jan 27 '12 at 17:50
  • just keep doing that – ren Jan 27 '12 at 23:42
  • 1
    @Kyralessa: My bad. I said 8000 developers when I meant 8000 employees. Must be more around 1500 developers. – ereOn Jan 28 '12 at 15:47
  • 1
    @jberger Even MS doesn't use VSS. I'm not sure they ever have actually... – Andy Jan 28 '12 at 21:31
  • 1
    @TC1: sure, but... I'll tell you my experiences of the last year. I've had to learn .net and a new API, and then another mostly-the-same-but-different API, then a new GUI system, then a new biztalk-based server API, then a new DB system (with tools) and a new security framework. And currently they tell me the biztalk stuff is rubbish and needs to be replaced with a new ESB. And to top it all, none of this works as well as the old stuff. Learning new stuff is ok, but I think the industry does too much of it. They aren't focussing on producing good stuff, but dreaming about the future. – gbjbaanb Feb 04 '12 at 01:00
  • @gbjaanb: Thanks for sharing your experiences. Obviously, too much change can bring as much trouble (if not more) that a lack of change. However, in my situation, the tools and code style haven't changed in 10 years. As in many things, I really think there is a good balance to find here. – ereOn Feb 04 '12 at 01:08
  • @gbjbaanb Change for the sake of change is not what I meant. What I meant was that there **is** a learning curve to **every** technology, people should just recognize this and realize they'll be making a better, cleaner & much easier to support product once they get over that. I mean, there was a time when unit testing was considered to be "a waste of time", because "writing all that extra code is bs when someone can do it by hand"... – TC1 Feb 04 '12 at 10:52
  • 1
    This question shouldn't be closed. It should be moved to workplace.stackexchange.com. – Kyralessa Aug 29 '14 at 21:33
  • @ereOn: The most effective way is to tell your boss you will pay for 2 weeks wages for each of the 8000+ employees to cover retraining and lost productivity during the switch over. – Brendan Feb 16 '16 at 01:28
  • @Brendan Does it mean I will also get paid for all the time saved by switching to more efficient development practices ? Neat ! – ereOn Feb 17 '16 at 00:17

9 Answers9

46

Aim for the head: "Lead by example" should have improvement in mind, but it should be targeted on people not on technology. Maybe you have invested too much time in improving technology, but not enough time in what is going on in their heads. Think about the driving factors why there is an opposition for new things. In many cases they just fear some risk. Identify those risks and find counterarguments for them.

Grab the fresh meat: It is easier to win over employees who want to change things. You notice them immediately when you see them.

Avoid the rotten meat: Some will never sympathize with your ideas. Leave them aside.

Grow to a critical mass: Find people who sympathize with your ideas. Win the over one by one. At some point if a critical mass is reached, more and more people will follow your example voluntarily.

Management vocabulary: Managers are not interested in better designs. Their language is money and time. Make clear how much man hours are wasted for bugs. Make clear that unsatisfied customers who encounter bugs are not profitable. Demonstrate how much faster you can implement a new feature. You need to choose another vocabulary for managers.

It is all about processes: Better technologies do not make better programmers and programs. If you have good running processes, even outdated technologies lead to good results. Think about were effort and time is wasted. Maybe it is not the technology, but something in the processes is going awfully wrong. In most cases it is a lack of communication.

Find a new company: You already have done a lot. You can still try to improve things, but it is also up to you to decide how long you want to try it and how much energy you want to invest. Keep in mind: Even if you cannot achieve a lot of improvement, you will learn a lot out of your efforts. At some point you need to move on.

Theo Lenndorff
  • 2,534
  • 1
  • 18
  • 15
  • Thank you very much for these advices. Regarding **Grab the fresh meat**, I already have on my side the only other young employee in my departement. Also, what can you do when the rotten meat is considered by almost everyone as the technical expert ? – ereOn Jan 27 '12 at 09:55
  • 3
    Related to "grow critical mass": http://www.youtube.com/watch?v=V74AxCqOTvg – back2dos Jan 27 '12 at 10:02
  • Sometimes you need to slap down the "fossil experts". Do it in a nice way though and not in front of there manager or something like that. Make it painfully obvious that they don't understand the new techniques like distributed versioning and simple branching. Then tell them to read 5min in Wikipedia. After a few times others will respect you more and consider you an expert. –  Jan 27 '12 at 10:16
  • 2
    @Farmor if you cannot convince them without say "go read a web page", perhaps you is the one who need to brush up on the communication skills. –  Jan 27 '12 at 12:41
  • 1
    I mean if they are stubborn and don't listen to the young. You can make your point by referring to documentation. For example if they say your points are not correct and almost all versioning experts writes your point they will be forced to submit. And I like to tease the arrogant, For example if they like Torvalds you can say Torvals says "If you like SVN you are stupid and Ugly" as he did in his google speech. I don't understand why referring to documentation when a stubborn person won't believe you is the wrong thing. You could even do it on your phone and show them right away. –  Jan 27 '12 at 12:53
  • Why wouldn't the manager be interested in better designs? something very bad of the company. If the managment chain, from each individual dev all the way up to the CTO, at some point contains people without technical knowledge/experience, that says something very bad about the company. Especially if it is a large company, as in this case. –  Jan 27 '12 at 12:55
  • @Farmor: I thought of doing just this but didn't because I fear the possible reactions. The guy in question has a serious ego issue imho. He often moans at Microsoft or other famous companies/libraries just because they don't do the things his way. He considers inheritance to be "school stuff that doesn't belong to the real working world" so I'm not sure that any written evidence that he is wrong would be sufficient. – ereOn Jan 27 '12 at 13:05
  • @Farmor if they do not want to listen because you not yet have proved your worth as a developer, then there might be additional issues that _any_ change of the process _MUST_ encounter in order to be acceptable. The "fossils" needs to be involved on that up front. –  Jan 27 '12 at 13:10
  • 6
    -1 for ageism. Sometimes you need to listen carefully to the "fossil expert" and allow yourself to have a little humility. Then with the knowledge you've gained make your idea even better. Sidelining others just because they're old is a sure way to lose valuable know-how and the support of influential senior devs. – Doug T. Jan 27 '12 at 13:35
  • @DougT.: I would agree with you. I don't believe age is the problem. The guy in question is not that much older: he is just unable to recognize his own weaknesses. – ereOn Jan 27 '12 at 13:53
  • @ereOn: Take closer look: Are really *all* technical experts against improvement? If yes: What risks do they fear? And: In many cases they also wanted improvements, but gave up at some point of time. Those people need someone to be re-ignited. If you really do not see any chance to win over some technical experts, then there are two possibilities: You have not tried hard enough or it is really time to move on. – Theo Lenndorff Jan 27 '12 at 15:19
  • 1
    @Lundin: Managers should have technical expertise, but the higher you climb the ladder the more money and time become important. There is nothing wrong with it, because someone need to keep track of the commercial aspects of a company. It is vital to give managers the right arguments into their hands so they can justify their decisions to their managers. As a developer you can win over a manager if you serve him the right arguments. – Theo Lenndorff Jan 27 '12 at 15:46
  • @TheoLenndorff: Of course. But there manager should also make quality a priority. That is, if they want the company to last longer than to the next dividend. As for time and money, if you have a person with no technical experience in charge of a software team, then that manager themselves is probably the biggest culprit, because they are most likely a superfluous person on the payroll. –  Jan 30 '12 at 07:21
30

Have you ever stopped to consider that you might be wrong?

So you read some designs and patterns books in school and you are disenfranchised with what seems like comparitively antiquated practices where you work. No doubt they are probably better ideas and new projects should start with these in mind, but it seems like you are on a completely different level.

Herding developers is like trying to herd cats, they inherently have a mind of their own, and a preferred way of doing things, whether right or not. I have a hard enough time enforcing best practices and managing a team of 2 developers, but you work for a company that has 8000.

That is a staggeringly huge number. Even a simple process change that states all developers must schedule meetings and out of office time on the public calendar becomes an enormously complex and difficult policy to implement across the board. It would also require a significant push from management to make sure the policy is accepted and adopted across the board.

You may not think it, but something as simple as moving from monolithic to multiple header files, or moving version control from SourceSafe to Git requires an enormous effort and investment on the part of everybody involved. It would require:

  • Significant management support

  • Company wide acceptance

  • Investment of meeting hours for all developers to inform them of the new initiatives (Meetings cost man hours, man hours cost money)

  • Training needs to be planned and established to make sure even the stupidest developers know what they are doing

  • Even assuming an hour of training, across 8000 developers x €50/hr = €400000 cost of training. This is more money than my one software development team gets budgeted in an entire year for salary, software and hardware. That is an exceptional investment you are proposing.

But you are saying, "Think of all the time that could be saved through productivity increases." Rightly so, but significant investment is significant risk, so I better be damn sure that you are right about this before I sign off on it. If none of the senior guys are backing you then I can't justify the expense. Ultimately we may be inefficient, but we are consistent and with 8000 developers across the company, consistency is the most important.

To do this you need sign off from multiple senior level people, and you need to accurately and objectively find a way to measure lost developer time to inefficiency. That time equates to dollars and only dollars and politics will help you win this battle.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 4
    Thank you. To be honest, at first, when I came, for some weeks I was all: "What the hell, these guys have no clue !" then realized how wrong I was on many points. But after two years there, I am pretty sure some processes **can** be improved, and could solve many of the complaints I heard. I understand it is also a matter of opinion but if someone came to me with evidence that I'm doing something inefficient, I would at least listen to the guy because he is doing me a favor. My departement is only composed of 40 people, and only us do this kind of development. – ereOn Jan 27 '12 at 13:15
  • 1
    I am sure that they can improve, but like I said, it is different for me to change my behaviors and practices to improve, than it is to train and force 40 developers to do this. A non-technical manager is not going to listen to you without politically important senior people backing the idea. – maple_shaft Jan 27 '12 at 14:22
  • It's not just "could things be done better?". Replacing a source repository is a huge change. there are big costs to making the switch, not least of which is retraining all the staff. Then there is the risk. Are you 100% sure that there won't be some capability the old source code repository needs, that you aren't aware of, and which the new one wouldn't have? – DJClayworth Jan 27 '12 at 20:06
  • @DJClayworth: The VSS repository is only used as a basic storage system. Nobody ever looks at the history and they usually erase everything before copying the entire directory again. – ereOn Jan 28 '12 at 15:50
  • 1
    @ereOn Please remember you work for a business, and a business is to make money, not code. Unless it's a not for profit. In any case, your prime value to your customers is probably not "we will deliver you code with the quickest compiling makefiles in the industry". You should work out what matters to your boss (eg cut costs) and then work out the costs. Factor in people, and tool costs. – jasonk Jan 30 '12 at 09:12
  • Also don't forget there's an element of "chasing a moving target" involved. You might go to all this trouble to change to this year's "good stuff"; and next year some new coworker is going to be trying to push towards "next year's good stuff" and complaining that you are the old expert that won't change his ways. And then the year after that... – Brendan Feb 16 '16 at 13:20
7

What you've described doesn't sound like "lead by example" to me, it sounds like you made a proposal and were rejected. To lead by example you need to show people that your way is better. Of the problems you listed I see three that you can start using your own changes yourself.

Plain old makefiles which only support full rebuild.

Create your own makefiles locally and show how much more efficiently you're able to work with them.

monolithic headers files and projects with very few different files (but each has around 3000 lines of code, which sometimes takes care of very different tasks)

Either break up existing ones when you touch them (without breaking the build) or introduce smaller header files when you write new code. As people start to work with them, they'll realize they don't need the duplication.

no use of the "new" languages facilities (well std::string is not that new but nobody except me uses it)

Continue introducing new language facilities any time you touch old code or introduce new code. Make sure you're simplifying things. Don't be discouraged from this one. Most of us are lazy. If we see that a new language feature makes things easier, we'll adopt it.

After a few months, if other developers start adopting your improvements, then you can approach your boss again about more radical changes like upgrading your source control system. You need to make sure the other developers see the benefit though, or it will never go through. One way to approach it might be to suggest trying out Git on a small project that only a few developers are active on. That way you can promote it as an evaluation, not a full scale transition to an unfamiliar system.

Finally, if after several months of trying no one seems interested in improving how things are done at your company, you need to really consider whether it's a good fit for you.

Bill the Lizard
  • 8,408
  • 9
  • 41
  • 92
5

In addtion to Lionel Barret (which I mostly agree), consider also the possible motivation to the resistance.

  • Evaluate the cost of the actual process
  • Evaluate the cost of the process as it will be like yours

But also:

  • Evaluate the cost of the change in term of
    • Money to spend to setup the new environment for anyone
    • Time to spend to train everyone to be accustomed to the new mode (it may be easy for you, but not that easy for people who are not aware of what you are doing)
    • Elapsed time required to manage the change in a non-disruptive way.

I have a suspect: How many are in your company the people like you in term of age and culture (I men "school" and "type of school")? How many people like you are expected to be hired in the next 2/3 years and how many will retire or change their role in the organization?

My suspect is that you are in a position with not enough strength to change the company. In that situation, either the company will change you or will "expel" you (In the sense it will become your own wish to go away), if you're not able to wait for more time.

But may be the company is evaluating that the additional costs I told you can be saved allowing the change process to happen spontaneously by waiting the natural replacement of the people to happen. You're just at the beginning of a process you cannot see because has nothing (yet) behind you.

Emilio Garavaglia
  • 4,289
  • 1
  • 22
  • 23
  • 1
    Your guesses are spot on: I am indeed one of the youngest in my department. Some of them seems to realize that despite my young age, I have some valuable knowledge. I know and understand I still have much to learn (and believe it will be so until the day I die), but a lot of them seem offended by things they don't know. I don't want to push them away or steal their job or whatever: I just want to improve things so that everyone can work/live better. Will I have to wait to be older to gain some weight ? – ereOn Jan 27 '12 at 09:51
  • 1
    @ereOn: your driving is so noble, every sane person should want to work with you. – o0'. Jan 27 '12 at 13:01
  • @ereOn: "Will I have to wait to be older to gain some weight?" Not necessarily. Age is a value in term of experience in manage complexity. Is not a value in understanding new things (they are new to anyone, and having no backlog can be an advantage). It's not a "personal" problem. It's a problem of "critical mass". Until the people wishing the change are less than 20% they will be suffocated. If they are more, leadership become visible (and is not a matter of age). If a leader can reach 40% of a population the "new thing" will have proper citizenship. From 60% change is spontaneous. – Emilio Garavaglia Jan 27 '12 at 13:30
3

At this point I can only add a reference to the Joel Article Getting Things Done When You're Only a Grunt. The sections include:

Strategy 1 Just Do It

Strategy 2 Harness the Power of Viral Marketing

Strategy 3 Create a Pocket of Excellence

Strategy 4 Neutralize The Bozos

Strategy 5 Get Away From Interruptions

Strategy 6 Become Invaluable

I'd summarize the article as "Change has to start with you."

Community
  • 1
Joshua Drake
  • 350
  • 4
  • 10
  • 2
    I found GTDWYOG to be not very helpful. In my opinion, at least the title is misleading: someone who "is involoved in hiring" or has the freedom to ignore the rest of the world while working in the cafeteria is not a grunt. A grunt is someone who has to do as told, with little to no control over the circumstances he is in. In my experience, despite the idealistic picture painted here at stackexchange, that is the case for most developers. And for those, GTDWYOG is more a recipe for beeing fired for disobedience. – keppla May 07 '12 at 12:45
1

Sadly people get stuck in a rut and develop the mentality that 'it works, everyone uses it okay, why change it' And it gets infuriating.

You have gone about it the right way by not just complaining but by developing a workable solution as a replacement, now you just need buy-in.

Show your direct line manager (or technical lead). If they are uninterested, do you have anyone in charge of change control or innovation?

Potentially though, your ideas and work could be ignored and the situation will stay as it is.

Amy
  • 790
  • 4
  • 8
  • 2
    ah but the number of times I've heard "lets rewrite it, it'll be so much better and cooler in new tech x" only to find that the new one was no better than the old (and in many cases worse). Quite often, until there is a *need*, it's best to not break something that works. – gbjbaanb Jan 27 '12 at 14:13
1

You need to state your case in a way that get your boss on your side. BTW, This kind of change is proposed by a technical director or project manager, so will need to commit yourself to the project. (As an alternative route, you can propose a technical audit, an outsider is likely to say the same things as you but will have more weight.)

So far, he doesn't see the need to change, it looks like cosmetics change to him : Costly without obvious benefits except to satisfy the fancy of a dev. Only two things matter to him : the flow of money and a stable team. The tech is a black box, if it works, that's enough.

First money, you need to proove that the current setup is costing him money. What the cost/hour of a dev and how many hours faster compilation times would save him ? Do the math. Also, compile articles or testimonies about the risks of the current code pipeline and show him scary numbers : "because of SourceSafe/Bad Coding Practices, our company lost $XXXK".

Second the team, your boss may be stuck with old grumpy coders who don't want to change their ways. If the first point is established, you also need to propose a solution to this problem. How many are you ? It could interesting to underline that it will hard to replace someone because the current coding pipeline is bizantine. You need to propose a plan to update the team. Learn them the industry best practice and check they are following the new rules.

Finally, you need to propose a plan to change the codebase, divided into small projects, with milestones and resources allocation. In fact, you're selling yourself as a project manager and the changes as mandatory to have a solid code pipeline.

Lionel Barret
  • 176
  • 2
  • Thank you for your advices. The thing is that the person in charge seems to like very much all the old developers (because in the end, they get the job done and don't count the hours). I feel I have very little weight because I am young. Several people in my department come to ask me things about good practices though but even when I explain things very humbly, at some point they don't want to show they know not much about it and try to defend their old ways. – ereOn Jan 27 '12 at 09:41
1

Do you work at an organization that believes doing things well, efficiency and innovation lead to success and profitability; or that the pursuit of revenue, and concentrating on maintaining sales are the tenants of success?

Companies that behave like you are describing are technologically entrenched. In a competitive market they wouldn't be able to compete with a company who focused on individuals and innovation.

If you are the person you say you are, then work somewhere that honors and rewards your spirit. Eventually after years of settling you will start compromising for the same philosophy that your superiors embrace. Go work somewhere else (probably a smaller organization) that values hard work, inspiration, creativity, and progress.

If you don't take a risk and do this soon you will eventually settle and you will not be able to continue to feed your curiosity and creativity because it is philosophically opposed in your current peer group.

Excellence is an attitude and a world-view.

Just know that this experience gave you the insight to know what to avoid, keep your keen eye for complacency and protectionism so you can detect it early.

In your next interview ask questions like "What kind of innovations come from your employees", "What are some changes that came from individual creativity?", "What individual talents can I bring to this team?", "What drives your organizations success?", "How is your organization continually embracing technological innovation?"... The answers to questions like this are extremely telling. Many organizations have no vision, or those that created the vision are gone, and the organization is ran by accountants. If you are interviewing with the Director of Technology - ask him if he sees the organization as a technology company.

Ben DeMott
  • 601
  • 3
  • 9
-1

If you do not like the environment you are working in then you are doing a disservice to yourself. You need to be surrounded by people who have similar interests and goals as you do professionally. I know sometimes that is easier said then done, but the feeling of looking back several years and feeling as though you have wasted your time is worse than the fear of taking a risk.

As an alternative, if you want to develop in a system or an environment that uses specific technology and/or methodologies then I suggest you find a project outside of work that you can contribute to. At the very least the variety of working on both systems will satisfy the need for something different while you find where you belong.

Seems to me you are fish out of water. Go find your body of ocean and swim!

wavedrop
  • 101