-6

So I have been working at a startup for over 6 months now. Two colleagues already have expressed some aversions to using TypeScript or formatters such as prettier when writing code, but if you are going to ask me to do a PR, I am going to comment when I see use of var as opposed to const and let, basically ES6 and beyond as opposed to just whatever floats the boat of the latest hire which is typically using CommonJS module system for new projects because they have not learned the ES2015 Module system and if a project is already a ES2015 project they still use CommonJS module patterns in it or run node index.js and say see, no complaints from TypeScript. Right, thats because TS does not exist in when running node.

The two founders, seem okay with just getting product out the door as soon as possible rather than following European Computer Machine Association standards and proper use of TypeScript.

Not sure what to do, but I am sure the nay sayers are positioning this to be an issue of me just wasting time with industry standards as opposed to getting product out the door as soon as possible.

To be clear, I am not sure how others interpret standards, but these standards are to catch bugs or to assist in doing so, it's the whole modus operandi of TypeScript and it's the reason we use const and 1et instead of var. With var you can accidentally mutate that state inside that variable and never notice until it's too let, with const you will not be allowed to screw that up.

What to do?

2
  • 2
    I prefer a Compile-time error any day over a runtime-error.
    – DarkCygnus
    Apr 21, 2022 at 4:13
  • 3
    Errors like "let" instead of "late" should always be found - proofreading and error checking is needed.
    – Solar Mike
    Apr 21, 2022 at 6:47

4 Answers 4

2

What to do?

You can see this as a technical decision. Or as a "effort vs cost" decision. And that would not be wrong. But you could also see it for what it is: your company hired people that aren't up to the job. At least not to the standard you expect.

Let me make a comparison for the non-programmers who read this. When you get an office mail, sometimes you get mails that are gramatically incorrect and full of spelling mistakes. And the writer will at some point say "sorry, I didn't have much time and didn't pay attention". And they think that this is a good reason. What I see is not someone who did not have enough time. What I see is a person so inept in this skill (in the case of the email riddled with mistakes the skill of communicating in their native language's written form) that doing it correctly costs them actual, conscious effort. They just told you, that if they do not concentrate their full brain power on the task of writing in their native language, something that should come effortless if you finished school, they cannot do it. If writing simple but correct English takes longer than writing bad English, then English is not a skill you have mastered. You are still an apprentice. I mean we are not talking Shakespear here, we are talking about an everyday conversation through email. The problem is not time, the problem is skill. And since skill is lacking, they need more time. Needing more time is the visible effect of the problem, not the actual problem. The actual problem is missing skill.

And to end this analogy, and come back to programming in the office, I personally want to work with people who write code clean and precise and maintainable as default. If this is "extra work" that costs "extra time", then they obviously lack skills that I expect from my colleagues.

If someone told me to save time by not capitalizing certain words in English, I would probably need extra time to make sure my muscle memory doesn't capitalize them. Because I don't think about it consciously.

So if someone tells me they save time by not following the little rules of programming, what they actually tell me is they are not skilled enough to follow those simple rules in their sleep.

So what can you do?

Well, your colleagues -by their own admission- lack basic skills and they won't learn them overnight, if ever. You can accept that because they pay you enough to work with less skilled personal, or you can find a company that doesn't hire clowns. But it's highly unlikely that they will change, just because you say so. Their standards might be lower than yours or maybe they simply don't know enough to even have standards. But that's how they operate.

1
  • you get it. Thank you, I am not insane after all. I have given myself two weeks to figure out where I want to go next in my career and if this start up will be a part of that future...exciting times.
    – Daniel
    Apr 22, 2022 at 2:49
10

The founders may have a clearer understanding of the phrase, "Don't let perfection get in the way of good enough." Unless there are specific industry standards that your software must be certified to meet, the "good enough" principle is going win over perfection every day.

I love standards and processes but I also understand they come with an initial cost and not everyone is always a fan. You might want to try starting with a style guide. If you can pull it off, that will get people moving in an agree-upon direction.

Also, remember that the goal of any software department isn't to generate beautiful code, it's to deliver value to the broader organization. I'm pretty sure that's what your founders care about.

10
  • totally get you, but as someone who was interviewing for jobs not that long ago, in an interview "good enough" will not fly. They will want to see proper use of type annotations and so on and so forth and I guess what I want to avoid at all costs is learning bad habits.
    – Daniel
    Apr 21, 2022 at 1:16
  • I also edited my OP, because based on your answer I am getting the feeling that once again, the point of these standards is being missed, its not for style or to look beautiful is to help us catch bugs.
    – Daniel
    Apr 21, 2022 at 1:24
  • 4
    @Daniel What "will fly", isn't up to you. Unless you're the CEO who gets to set the standards. If you don't like organisational standards, you should consider leaving. Make sure you include how important "let" is to you during your interview. Apr 21, 2022 at 2:44
  • 1
    "Don't let perfection get in the way of good enough." - I'm writing that one down ;) ... oh I am a bit torn with this situation you describe @Daniel but I do think that the Style Guide will give you something more tangible and structured for the CTO and others to have as a starting point for you to propose. If your concern is that people are confusing your posture as "seeking perfection" but you actually want to catch bugs faster, then do include on that Style Guide (or in demos) ways or examples of how a guide can/has helped catch bugs faster.
    – DarkCygnus
    Apr 21, 2022 at 4:12
  • 2
    @DarkCygnus, now there is an idea I can get behind. Thank you.
    – Daniel
    Apr 22, 2022 at 2:44
2

If you look at it from the other side. Those chaps are not being paid to change how they work and you have no authority over them. So you can expect resistance unless you can show them how it will benefit them in the short term.

Which as far as I can see won't happen. They already have bosses and you aren't one of them.

Which leaves your bosses to decide if it's worth the effort and tension to take your side. This is risky because if 2 performing workers have an issue with a third, it's a fairly simple equation that the third is the problem. So be prepared for any pushing to potentially go against you.

There is two ways to make a change. One is through the hierarchy which hasn't worked. The other is sideways by showing your colleagues how it will benefit them personally and tangibly in the short term. Not how it will benefit the product or long term benefits for the company. It's not their product or company. It's a startup that quite possibly won't be around in a year or two.

13
  • @Killisi, I am never clear how people misinterpret my posts. Correct, I am not their boss and they are not mine, but I am being told NOT to follow standards by these same guys, that I have it wrong.
    – Daniel
    Apr 21, 2022 at 2:00
  • 1
    Sure you are, that's a defence mechanism. Justification/rationalisation for just continuing as they are. Recognise it for what it is, not it's face value.
    – Kilisi
    Apr 21, 2022 at 2:03
  • yes I do know its a defense mechanism on their part, my concern is when it becomes disrespectful, the talking down to, because I suggested a fix that takes one second and can avoid a world of problems afterwards.
    – Daniel
    Apr 21, 2022 at 2:06
  • 3
    Thats how it works unfortunately. The more defensive, the nastier it can get. Normal social dynamics
    – Kilisi
    Apr 21, 2022 at 2:09
  • 2
    @Kilisi Just for your info, the specifications don't mandate or even recommend you avoid "var". When Daniel says they are not following "ECMAScript specifications" he is incorrect. They are going against some style guides, of course, but not the spec itself. Apr 21, 2022 at 5:00
1

Consider a return-on-investment perspective. You’re at a startup. Money is limited. Apply the formula: Average hourly cost of employee X time discussed X number of people.

Is a conversation, block, rejection, or code update of a feature due to var vs let going to affect the bottom line? Is this worth potentially thousands of dollars in the near term? Have you achieved minimum viable product and gone to market? Is there substantial net gain by enforcing it?

Standards are great but functionally (and historically) startups need to focus on revenue and that means MVP and new features as quick as possible—not beautiful and semantically correct code.

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Apr 21, 2022 at 3:47

You must log in to answer this question.

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