63

I design electrical circuits for a living. Over the past few years, I've established a logical design method which works for me and helps me to keep track of how everything is connected together. Since these designs can become humongous, I group the sub-designs in a specific way, name my nets in a specific way, etc. This isn't a matter of right/wrong, but rather just how I think about things.

I was the only designer in my company for a number of years. A couple of months ago a coworker was hired to take up some of the work. I've found his structure of doing things to be difficult to keep track of. He seems to think very differently to myself and organises his designs in a very different way to me. I did speak to him about it, but he said this is what makes logical sense to him. Nonetheless, when I look over his work, it takes me double the time it would take to figure out what's going on than it would if it were my own design.

He is significantly less experienced than me (I'm at 10-ish years, he's at 2). I don't know if his method is due to him not really establishing himself yet or if this really how he does things.

How can I find common ground with my new coworker? I want to be respectful of him, but his design style is really getting in the way of our progress as a team.


To clarify where my techniques came from: I was trained by a company who was much larger and had an established internal design standard. I didn't question where this came from. When I started at my current employer, one of the first things I asked was "what's your design standard?". They didn't have one, and I was pretty much left to use the techniques that I'd learned. These have evolved slightly to fit the needs of a smaller company. I have only really worked at these two companies, so haven't been able to objectively evaluate my design process relative to the industry as a whole.

  • 3
    How much extra time does it take your colleague to work with your designs? This question is much easier to answer is one of the two approaches is objectively more effective :) – Erik Jul 18 '17 at 8:18
  • 6
    @TotumusMaximus sure, which is why I want to be careful in considering his opinion instead of just declaring my way better. – user5621 Jul 18 '17 at 11:09
  • 86
    Is nobody going to point out the electrical circuits/common ground pun?! – Jake Jul 18 '17 at 13:13
  • 7
    in programming, it's common for teams to define a style guide, which says things like "if you create a variable which is a constant, precede its name with an underscore". usually, teams use style guides that have already been written by others and are published online, such as the gnu style guide. when there is no well-written style guide available that suits a certain use case, the team works together to craft a style guide for their project. – Woodrow Barlow Jul 18 '17 at 14:26
  • 3
    You have spent several years working alone, and developed a set of personal work-related habits. There is absolutely nothing in your post to demonstrate whether these are good or bad habits, but (almost by definition!) you think they are good, otherwise you would presumably be working some other way. Either you need to learn the basic lesson that "there are more ways to skin a cat" than the one you are currently using, or you need to move to another job where you don't have to work with anyone else! – alephzero Jul 18 '17 at 15:02
102

I design electrical circuits for a living.

How can I find common ground with my new coworker?

You worked all alone for years. Your standard makes sense for you. You should really look around for the industry standard on this. Sooner or later you will either hire more guys, or maybe you will switch companies. Designing electrical circuits is not exactly hipster territory. People have done this before and they had the same problems you have. How to keep organized.

You have this problem with 2 people, just imagine companies with teams of 10 or 100. They have standards. Find and read some and then decide together if you want to adopt one of them or build your own based on those. A standard also helps in onboarding new workers. They can read it and adapt instead of your team having to correct them every time until they are frustrated.

So go find the industry standard(s). Then pick one.

  • 2
    This is a good point. I haven't worked alone for my entire career; I was trained by a very experienced designer for the first 4 years or so who formed the basis for the techniques I use today (it has also evolved somewhat since then). That company was larger and had a design standard, but I don't know if it was based off of a more officially recognised one. I'll look into it. – user5621 Jul 18 '17 at 8:31
  • 66
    +1 And I want to emphasize the decide together part. Don't just pick your favorite and order your coworker to follow. You need to have a discussion about what makes the most sense for your designs, your workflow, and for the two of you. – David K Jul 18 '17 at 11:56
  • 7
    Looking around existing circuits, either there are really many standards, or they are generally not followed. In either case, there is a matching xkcd: xkcd.com/927 – PlasmaHH Jul 18 '17 at 12:04
  • This may be overkill for a small company, if the guy's stuff is to a good standard and works, and doesn't overly inconvenience you, I'd say leave him to it rather than beating the poor guy over the head just because he does things different. – John U Jul 19 '17 at 11:01
  • It also really depends on the position of both of you. If the new worker has a position that is equal to yours he might see you trying to work together to create a standard as a threat. I suggest you first go to your supervisor and get him on board. Sell to the supervisor the advantage of creating and documenting a standard. Then the supervisor will ASSIGN the task to both of you to create that standard. It will certainly take time to do this, especially writing up the documentation and that need to be approved by the higher ups regardless of if the other guy things its a good idea. – Phil M Jul 19 '17 at 16:14
13

We have similar issues in coding, with regards to style and personal preferences. Occasionally someone will come along who feels very strongly about a certain thing (tabs vs. spaces, when to put the brace on the next line, etc.) and, if they're obnoxious, they'll make some kind of wide-reaching commit that makes everything conform to their way of doing things. Alternately, they might tie up the whole team in endless discussions about something that doesn't matter as much as they think it does (the materials of the bike shed).

The answers to these sorts of problems begin with conformity. There's nothing worse than having multiple standards half-applied because different members of the team either ignorantly or knowingly work against each other. If you spend the majority of the time working on your own designs and can respect each other's approach when you do have to work on theirs, it's not a huge impact. However, if someone spends an adverse amount of time converting to their preferences every time something passes over their desk or passive-aggressive yo-yo'ing of changes occurs, you have a problem.

Secondly, don't rock the boat. If you have a consistent standard that isn't your favourite, keep it consistent and don't change it purely out of personal preferences. Such efforts usually have very little benefit and the chance of introducing hard to find errors. Starting a new project is the right time to be selecting a standard. Any mixed-standards within a project (from new contributors failing to follow an old standard, or just a decision to switch) can leave things messy and confusing.

The third thing you need is leadership. Pople like to talk about this stuff but it's not always the most productive discussion to be having. Do take some time to talk about it, but ultimately someone needs to put their foot down and make sure everyone adheres to the same standards.

So my advice to you would be: have a discussion with him about his style, but ultimately come to a final decision on a singular style you can both live with. Learn his style and how to respect it for existing designs, but for all new designs use the agreed common style and hold each other to it. Don't be afraid to iterate on what that style might be and discuss it further, but make sure such changes are agreed and understood by all involved.

  • 8
    I don't think that tabs/space or brace placement are equivalent. Those are cosmetic and the changes can be automated. From the OP's description it seems to me his issue is with architecture of the design: Since these designs can become humongous, I group the sub-designs in a specific way, name my nets in a specific way, etc.. I've never seen software standards for such architectural decisions. – Matthieu M. Jul 18 '17 at 14:46
  • On top, a programmer that joins another one that has years of working for a company (established codebase) deserves to be fired for just wildly creating chaos in said codebase. Consistensy is a quality of it's own - unless the establisehd way is utter crap (which happens). – TomTom Jul 18 '17 at 15:35
  • 1
    @MatthieuM. When I created this question, I initially wrote a programming analogy since I happen to do quite a bit of programming, but then realised that software architecture is different from hardware architecture and it wouldn't be representative of the actual question. – user5621 Jul 18 '17 at 16:59
2

Identify gaps

It is relatively easy to get into friction with people who don't quite think like you. Brothers brought up under the same parents often do run into friction because of such differences. The first step is to identify where the gaps are. How severely do we have disagreement or not, which areas have more serious gaps, how does these gaps affects us beyond just basic comforts: for example, does it affect productivity? or final outcome of work?

Understand mutual point of view

Why does the other person think differently, because of their point-of-view. these gaps reduce as you have more and more communication. As we meet people who are different from us, we learn more : example-by-example. More you have open communication, more we can analyze whether or not the other person will be in agreement or disagreement irrespective of our liking.

Learn to isolate deliverables and dependencies

Some aspects will never get resolved because it is fundamental to our personality and core ideas. So as we learn to identify what seems unresolvable, we must identify ways in which we can separate out responsibilities or simplify how we can remain agnostic to each other's point-of-view and receive-deliver the work required mutually and for the organization.

Escalate positively

When things doesn't seems to be easy, or affects work be objective about where the thoughts differ mutually and how it affects the final output of the work. Present this to your higher ups who has the authorities to split the domains, or work areas or setup processes that simplifies these friction issues.

Don't take the friction home or onto your head

While it may take time to resolve gaps in people's thinking, and adults definitely won't give up their ideas easily. So there will also be periods where these frictions does make us uncomfortable. Be objective, and do not take elements of these disagreements personally. That will be essential for you to have your work output productive and of quality and will let you have peace of mind when you go back home.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy