1

I'm working in a small "team" of 3 programmer, each working on seperate projects. Therefore I'm using in-house SDK's to write software for MCUs, designed and constructed by our company.

The SDK documentation is very poor, more a reminder for the coder who has written the SDK. Many parts of the docu are raising more questions than they answer.

The SDK is written by the senior programer who is also one of the companys founder. Second beside me is a young professional with a few years of experience, I'm trainee.

The MCU's documentation is okay. I got some problems interpreting everything due I'm a programmer, not a electrical engineer but I can understand it somehow.

Most of the time, when I ask the senior coder something I regret it immediately due he is pretty harsh and thinks everyone is stupid who can't understand his thoughts (There are rumours he is autistic, but I don't know for sure.). Also, he has no time for anything except his work in this very moment, so 'disturbing' him is like a walk in the dragons cage.

Second coder is willing to help me with a lot but he doesn't know everything. Most of the time he writes desktop applications and he does not need the in-house SDKs very often.

CEO has written some scripts many years ago and thinks he is a "average" programer, if he had to write code. But talking to him reveals he has no concept of what programming is today, he wrote some assambler scripts >10yrs ago but never used a high language like C# or .net. He thinks the documentation is good for our purpose and says the senior has no time for us two coders.

How can I deal with that? I feel like I must climb the Mt.Everest with only a 2 feet rope.

  • 2
    Can you gather a bunch of questions together, and arrange a meeting - ideally a regular one - with the senior programmer, to go through all the stuff you don't understand? I mean, it sounds like he's not happy with interruptions, but would it help if there was a fixed time, which he knew about, for him to tell you the stuff you don't immediately understand and can't work out from the SDK? – Hazel Jan 15 '15 at 12:18
  • 1
    This question would read better if it were dejargonized. I know what an SDK is because I'm in software, but I have no idea what an MCU is without googling, because that's not my domain. Keep in mind that WSE is not industry-specific. If your question is specific to the software industry, it might fit better at programmers.SE. – shoover Jan 16 '15 at 16:26
  • Do you have access to the SDK code? – user8365 Jan 16 '15 at 22:38
7

Turn this into an advantage for you. You are a junior in a software company and it's your job to learn. Not just about what is right, but what is wrong, as well.

Use the time that you have to learn why the SDKs in question are poor; don't focus on the people. If you think about this the right way, you can progress yourself beyond these people that are living in the past.

Use your spare time to learn the "right" way. Use and contribute Stackoverflow. When it comes to being given a new project to work on, from scratch, put into practice the things you have learned in your spare time.

You can still learn from the senior and the CEO. Keep quiet, keep learning; and then when you have enough experience and knowledge, move on to a non-junior job in a year or so. Working with poor codebases and practices isn't a bad thing at first, it adds to your experience and helps you realise why you might need those annoying little things called "standards" and "best practices" in the first place, and you will be a more rounded developer for it.

  • Addition: This answer comes from honest experience. Pretty much the same shoes. Put in the effort and you will soar past them within a year or so. I know. I did :-) – James Jan 15 '15 at 11:19
3

Jimbo has an excellent answer but I think there are some things you can do beyond get better and learn.

It's funny that you state that asking the SR dev questions is like 'walking into a Dragon's den'. Documentation is a beast. Software devs, perhaps especially crusty, grumpy, oldschool software devs, often have an extreme allergy to documentation. Often you'll hear the cry "Good code should be self documenting!" But, let's be honest here, if you want anyone else to develop or use your code then you have to have sensible, usable documentation.

Let's also take a moment to point out that any CEO that says things like 'the senior has no time for us two coders' would be, given the rest of your description, a huge red flag for me. Reviewing those flags - the Sr dev has no time for his team, documentation is lacking or incorrect, onboarding was non existent, there's 3 devs all working on completely different projects using an inhouse, undocumented SDK... To be completely honest, if I were in your position I would be job hunting because this sounds like a place where whatever you 'learn' will be some proprietary, inhouse weirdness and that there's little to no chance for career advancement.

That being said, you seem to want to climb mount everest with 2 feet of rope and a bunch of dead weight hanging off of you. So how can you do that?

First thing's first. Documentation is poor to non existent. Pull Request accepted! Whenever you come across something that is undocumented, poorly documented or incorrectly documented - make your own documentation. Share it. It is possible to be an amazing developer and write acceptable documentation. One of the fastest ways to show what you have done, what you have accomplished and be seen as effective is to have documentation you can point to. You're figuring out this nonsense anyway, it takes the space of a few minutes to write down what you figured out. Next time you have that to refer to. Often documenting widgetA can lead to an understanding of how widgetB should/could work. In short documenting helps solidify your understanding of a specific object, gives you more general knowledge to the overall project and begins to put you out there as a domain knowledge expert(as your documentation proliferates and expands.)

As an anecdote for this - my first IT support/weird dev job used a lot of in house tools and had some crazy workarounds and requirements due to the nature of the work. When I started, and throughout my time there, whenever I came across something new I wrote it down. I dumped these in a repo called 'Nahkki's Wiki'. I quit that job 7 years ago, I was back in town meeting with an old coworker who still works there and people who I have never met are still using and expanding 'Nahkki's Wiki'. Every time someone had a question, my name came up because I had documentation around it. A small, cynical part of me things that people trust things that are written down more than things spoken - which meant they listened more when I said "I have a doc for that!" as opposed to "This is why....". In my last Software dev position(in a research lab) and in my current software dev position I've done the same thing. And what do you know, I've been at my current position for 6 months and boom Nahkki is the subject matter expert in the silly, weird in house framework because she wrote all the docs...

What I'm saying here is that writing the docs, though reviled by many people in our field, is a great way to gain knowledge, experience and visibility when you take the time to make it part of your workflow. Anyone can write code, trained monkeys can write code. Not anyone can make code that others can use and extend. Making that code requires appropriate documentation.

Beyond writing the docs as you go(which I really can't emphasize enough) I would challenge your supervisor. If your supervisor says "The SR dev doesn't have time for you" then your response should be a respectful "when I have questions that are blockers how should I proceed?" I would recommend scheduling times to meet and ask questions. You and the other devs are using the same SDK - there should be a regular meeting where you talk about what you are doing now and what blockers you have run into. Never ask a question twice - ask it, understand the response and document it. You should phrase all of this as a blocker to productivity(because it is) and your supervisor should want to make this better.

Frankly, if it were me, I'd be waltzing out of there as soon as possible. Sure you can learn a lot from a crummy situation, but you can learn all that and more from a good or even great situation.

Not the answer you're looking for? Browse other questions tagged or ask your own question.