1

I've just joined a startup (first day finished). And there's a few things i've already noticed are a little off kilter.

The major is that a fundamental piece of the engineering (RPC) is a framework that one of the previous engineers rolled on his own - It's JSON over HTTP POST... the mind boggles as to why they didn't choose Thrift/gRPC/ProtoBuf etc..

(My apologies for the tech references.. my hunch is that there are many techies here and it may help..)]

Anyway, I feel like I need to raise this as an issue sooner rather later. Should I take it to the tech lead or straight to the CTO or raise it for chat on the Slack channel.. Now, it's a small startup so the CTO is involved in most stuff.

As opposed to just crying about it I am going to propose some problems and suggest that I work hard to solve on my work and have the solution trickle out to others..

What have you done in this case? Thanks.

Improve this question
8
  • 2
    Also strongly related How can I suggest a list of improvements to my leaders/team without offending them?
    – DarkCygnus ♦
    Commented Sep 11, 2017 at 17:34
  • 2
    You bring me to one of my pet peeves cum favourite quotes: before you criticize a solution, understand the problem it was trying to solve.
    – Masked Man
    Commented Sep 11, 2017 at 17:42
  • 1
    Surely JSON/HTTP is REST rather than RPC as such?
    – Dan
    Commented Sep 11, 2017 at 17:54
  • @Dan yes but it's implemented in a RPC kind of way if that makes sense.. All calls are POST.
    – jim
    Commented Sep 11, 2017 at 17:56
  • Why do you consider a RESTful API to be 'technical debt'? Many, many systems use this and they work well. Somebody else might look at your solution using Thrift/Protobufs and ask "Why didn't they just use REST?"
    – Ben Cottrell
    Commented Sep 11, 2017 at 21:06

2 Answers 2

Reset to default
7

What have you done in this case?

Do not assume that what was done was plucked out of thin air. I might hold on to my opinions if I were you until you are 100% clear as to why things are done they way they are.

This is not to imply that you are wrong, I just suggest you be 100% sure of your correctness, which you cannot be after 1 day.

After you have been there a bit, and know all the in's and out's, then bring on the suggestions using an incremental approach. Your delivery of these suggestions without crapping on the current implementations, and indirectly the people who implemented, will be critical in terms of how well your input is received.

Improve this answer
3
  • Valuable comment.. the debt I am referring to was written by a past engineer and I've heard people refer to the implementation as laggy/slow etc..
    – jim
    Commented Sep 11, 2017 at 17:55
  • But good point.. I don't think I should just fly in and be like ... change ... change ... change..
    – jim
    Commented Sep 11, 2017 at 17:55
  • 1
    @conor Yep, give it some time and take an incremental approach. Once they see you know what your doing and your changes are for the better, the next suggestion will be much easier to get buy in on.
    – Neo
    Commented Sep 11, 2017 at 17:56
1

What have you done in this case?

I have talked to my boss in similar cases and asked what was the process for collecting information on technical debt at this company.

Often, there is either a bug-tracking system, or a system to collect "Stories" or such.

Once I learned the expected process, I followed it.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .