Elysian Shadows

Ok, I could really use some good advice on this.

I am an asshole. This is a problem in professional settings.
My general policy to mitigate that is to be somewhat of a yes man and go into soppy retail customer service mode.
Obviously, this is not helpful to me or the work.

I recently got hired for a programming internship. I have two coworkers on the project, both classmates of mine.
One of these coworkers has a math degree. Both are "unconventional" students, as myself. Both are nice people.
Neither has a passion for programming. Neither is very experienced, which should be fine.

Our faculty manager (not really relevant to the work) has a hard-on for UML diagrams and other such crap.
The work we are doing is a simple, small part of a much larger ongoing project that will take thousands of man hours to become market-ready.

I am extremely excited about the work, as are my coworkers. Because I am a bit more experienced,
I have been assigned the role of team lead in an unofficial capacity.

My problem is that there is a huge disconnect between me and my coworkers and I don't know how to bridge the gap.
I don't know how to provide guidance or explanations without coming off as a douche. Example: my coworker with the
math degree doesn't understand simple matrix operations or their applications. Neither coworker understands simple
data structures. One is the "everything is a pattern recipe" type. Any suggestion regarding anything quickly devolves
into an excited rant about "Oh, that's totally a solved problem! This design pattern is widely used..."

What do I do? How do I approach this appropriately? Even if I write all the math and physics bits myself, I can't
cut people out of ALL the logic that matters in the project. If I convince people to work largely on GUI elements,
it's possible that those will suck and require double the work in the end.

I don't consider myself an expert or leader material, but I'm the only one available to lend guidance in our circumstances.
I don't know how to stay professional and avoid bruising any egos, and I don't know how to have productive discussion
if I can't find common ground with the rest of the team. I can't be accused of "mansplaining" (out of *necessity*), either.
I don't want to come off as arrogant to them, but we need to be on the same page and understand the same concepts.

The stuff we're working on is simple enough and on a small enough scope that I could do all the work on my own,
but having coworkers should mean that we can get even more done and hit a higher quality bar.

Sorry for the rant. I'm really lost on this. I don't want to seem like I'm writing off my coworkers--I'm not. I just don't know
how to approach the (silly) politics of this situation, and I don't want to get a bad rep because I can't communicate
with people.

Please help, if possible. Thanks.

Choose your battles.

First, let me introduce myself. I'm a self-taught professional software engineer, a lazy dropout, and I have a passion for everything related to this field. The people you're working with now were me eight years ago and only with the mentorship of my best friend was I able to grow as a developer and get to the point I'm at today.

Eight years ago I begged and pleaded with this friend to "make a game" and so for the next two years we spent between 20 and 40 hours a week writing something up. It was the worst pile of garbage I've every seen. Today, I'm 90% sure I could rewrite the whole thing over the next month. I mean, I'm talking some of the worst engineering practices I've ever seen much less done myself. You like singletons? You like awful object ownership? The project was doomed to fail and it did.

I asked my friend how he could possibly have let me do the things I did and his only response was "I had to pick and choose what battles were worth fighting." He's right and I can see that now. I'm sure somewhere inside, he realized the project was flawed at the start, but I think he was willing to stick with it out of compassion and because, even without success, it was still a fun thing to do. These things taught me some invaluable lessons about how to work, to measure myself, and how to learn without training wheels.

As for the relation to you? My friend, while he never means to be, is an asshole through and through. A passionate, forceful, argumentative, and intelligent asshole. That doesn't mean he's not my best friend, no, it just means that, like you, he has a much more difficult time communicating with tact and without being forceful, aggressive, and insulting. We've yelled at each other before and sometimes still do get into heated debates but I've learned that, more often than not, he's right.

I have no doubt that you're intelligent, you're hard working, and you're good at what you're doing, but given your current situation, my only real advice is the same as that friend of mine: choose your battles.

As for some practical advice, I have a few pointers:

Make your number one priority to implement a code review platform.

This is probably the most important thing you need when working with new developers because it gives them a chance to review your code (teaching them what good code looks like) and also a chance for you to catch mistakes in design and implementation before they hit the product. Be thorough with your reviews. I cannot emphasize how important this is.

Set up a build server and run automated unit tests

This is probably the second most important thing you should do. Without this, you'll forever be stuck with terrible code and it will never work. With this, you'll have confidence that the code you write actually works. Without this--and trust me, you don't want to live without this--your code will rot. On this same note, learn Test Driven Development and emphasize the basic workflow of writing tests first (gives a great idea of what api you're aiming for) and then writing code to make the tests pass. Do this in parallel forever.

If your team is all writing code with tests and you have continuous coverage, how could you possibly write something that doesn't work? Rhetorical, yes, but you get my point.

If you can, get a budget to run something like Travis CI. If you can't, use Jenkins.

Jesus Christ use Version Control

Sorry, but if you're not doing this, I think you need to go back to school. I take it back when I said code review was the most important. Using the right tools is the most important. If you need to, run your coworkers through a Git tutorial. This is incredibly important and, honestly, it's just downright embarrassing when someone of intern age doesn't know how to use Git. At least us young devs have an excuse for not using SVN and CVS.

Be patient and find different categories of work for each person

It's best if you can put them on a task that they can work with for a while. You don't want tight integration because you don't want to be blocked by them and you don't want your stuff to suffer thanks to their terrible code. Honestly, your code is probably terrible as well (because all young devs write terrible code), but at least there's a separation between what's usable in production and what's not. I wouldn't go about making this obvious though.

Most importantly, remember everyone was bad at some point or another

I can't emphasize this enough. There was once a point in time where we all wrote "hello world" because that's all we knew.

vmrob's response hits the nail directly on the head. All of my experience points to exactly the same conclusions. Couldn't have said it better myself.

The only thing I would have worded differently is "Choose your battles". Rather than thinking of your coworkers doing something incorrectly and you having to "battle" them over it, consider them necessary mistakes for them to move forward as a programmer. You can be told a hundred million times that "singletons are bad", "globals are bad", "OOP is unnecessary", so and so forth. But until you actually try to apply those principles in your own code, and see for yourself *exactly* why they don't work, you're never truly going to understand what makes this stuff "bad".

Next time you see your team doing something exceptionally stupid, rather than convince them *not* to do something they are going to do anyways, help them do it (within reason, of course. some things can be adequately explained as counter productive so that they don't need to be executed just for a "hah, told ya so!" moment). The faster they add that singleton, the faster they realize it was a dumb idea, and the faster they learn better ways to solve the problem. Never follow up with "See? I was right." Instead, ask them if the understand now why it's not the best solution and how this other thing is better suited for the job.

If you don't have time to do the above, then, effectively, you don't have time to teach. In that case, you need to hire experienced employees from the start. You can't expect a novice to become an expert in a week because you told him to.

Thank you for the feedback, guys.

In the team's latest report I suggested a stringent code-review policy--the team just kinda went along with it but didn't seem enthused.
Maybe I can get them to do it, though. Part of the difficulty is that we're supposed to be equals--the folks in charge just designated me
team lead verbally, because they know I show up and will put the required effort into reports, corralling people, etc.

In other words, they dumped some responsibility on me without giving me any real authority to facilitate it.

I haven't used a build server before, but it's a great idea. Especially since the project is VS C# and I'm running Linux.
Unfortunately we aren't being given many (if any) resources for the project, so I would need to A) get a cheap PC myself,
and B) set up the build server in my apartment. It may be doable, though.

The project is hosted on GitHub, so that's nice. I had to set everyone up to work, but I think they'll get the hang of it after
some practice. Because we aren't really being accommodated at all (college/company squabbling), I've convinced everyone
it makes more sense to work at home right now, which has diffused tensions a lot. If it takes effort to contact me, it doesn't
happen constantly lol.

My teammates have more or less already segregated themselves to different areas of the work, so it should be a lot easier
moving forward.

I don't have time to teach, and none of us were actually vetted at all for the job. Essentially, those of us
who took initiative to find the internship got hired on the spot, without so much as a question.

But, despite all that, I think we can make it work. Not dealing with people in person is definitely helping, and it requires each
of us to learn to work independently and discover how to answer our own questions. Thank God.

Thank you guys for responding to me. Your responses are very helpful and put things in perspective for me.

lelandbdean wrote:I've convinced everyone
it makes more sense to work at home right now, which has diffused tensions a lot. If it takes effort to contact me, it doesn't
happen constantly lol.

One more word of advice: be careful with this mindset. It's good to get away and cool off, but I can tell you from experience that obstructing communications is not going to help your team succeed. I'd much rather have a teammate voice their opinions to me (as long as they do it respectfully) than be silent. I've worked with people who are always quiet and seem perfectly fine, then one day they just quit and you find they've been having problems for the last 6 months which could have been solved in 20 minutes with better communication skills. It sucks.