3

Yesterday a middle manager told us that it's not allowed to use magic numbers in the code but don't explain why, and someone just asked what is magic numbers and why we cannot use that(many of my teammates do not understand that yet methinks). In this uncomplicated case, it's easy to just search Google and find the answer. But in some complicated situations would it better for a tech leader to add some citations for his/her rules? I know it may not his/her duty to instruct his/her subordinates.

I don't know if this is too trivial but any suggestions would be appriated. Thanks in advance.

Improve this question
3
  • 4
    "someone just asked what is magic numbers" Did the manager answer? If so, what is the problem? You want him to explain everything without waiting for questions? Or did he ignore the questions?
    – Chris
    Commented Dec 18, 2020 at 9:00
  • 3
    Do you have a question other than 'Do you agree with me?'?
    – jcm
    Commented Dec 20, 2020 at 10:17
  • What is the problem here?
    – guest
    Commented Dec 20, 2020 at 16:09

3 Answers 3

Reset to default
17

There's a quote out there that I can't find, but it says something along the lines of a senior engineer's job is to make more senior engineers. The same is true of anyone in a leadership position. Their function is to influence and guide individuals and groups to make the group stronger and better. Even if it's not formally in their job description, if they are truly a leader and not just a manager, part of their duty and responsibility is to make the team better, and one way to do this is to increase the knowledge of the team.

Coming from a software engineering background, I'd expect anyone with any amount of education in the field to understand avoiding magic numbers, preferring well-named variables or constants. It's not something that I'd expect to have to explain. However, I'd also hope that the work environment is safe enough where a very junior member would be able to ask and receive an explanation.

Not every statement needs to be explained. If it's something that could be considered a best practice, good practice, or common knowledge, I wouldn't expect to need to explain it. However, I'd be open to turning anything into a teaching moment. Depending on what it is, perhaps the more junior person can teach the more senior person. The most important thing is a safe environment for teaching and learning, where questions can be asked.

Improve this answer
3
  • This is well said - sadly we also live in a world where "junior hires" often are on a level that 10 years ago would have been rejected as trainees. RTFM - an unknown art. Using documentation in general - an unknown art. Skills so shallow that if something is not in a 20 minute "in depth" tutorial they do not know it.
    – TomTom
    Commented Dec 20, 2020 at 12:57
  • @TomTom, things were often simpler in the past. Can the average junior today possibly have worked with a stable technology for any length of time?
    – Steve
    Commented Dec 21, 2020 at 0:11
  • Ah, that makes ZERO difference because I am talking of basics they never learn. Patterns. Standard Data Structures - how many Juniors today know the difference between a Dictionary and a Linked List in Performance? This is stuff you learned in the old days. In germany (yes) Programming is a trade - 3 year education (like any other craft, i.e. electrician). This stuff is on the list of things to learn. You are no junior without this. You are a trainee.- and no, patterns and data structures have not changed at all. Neither have languages too much - I STILL do C# and I STILL have the SAME basics.
    – TomTom
    Commented Dec 21, 2020 at 9:52
3

But in some complicated situations would it better for a tech leader to add some citations for his/her rules?

Yes, of course.

If someone just says "never do x" or "always do y" without ever explaining the thinking behind it, then it is just "magic", and you'll never be able to generalize the benefits.

Instead, explain why it's not good to "do x" and why it's good to "do y". Then you'll be able to apply your learning when you encounter "z".

Improve this answer
2
  • Sometimes you don't get the chance to generalize. This reminds me of my first-day "health and safety" briefing in a shop-floor environment. The guy showing me around said "These maroon coloured gas cylinders are acetylene. If you notice one of them making a funny rattling noise, and if you are brave but foolish, you will shout as loudly as you can "Gas - evacuate" and then run like hell to the exit. But if you are wise, you will just run like hell :)
    – alephzero
    Commented Dec 18, 2020 at 3:42
  • I read somewhere that an apprentice at a dead run outranks a shop supervisor who doesn't know why the apprentice is running.
    – A. I. Breveleri
    Commented Dec 21, 2020 at 1:40
-3

I assume you are not allowed to use “magic numbers” in code because your clueless manager read about it somewhere. So he or she can’t explain it, because they don’t understand what it means.

Any sentence containing “never” is wrong. Without exception. (Hope you figure out the problem with this statement). If I notice you are using “magic constants” I will explain to you why it is usually a bad idea. And if you have half a brain you will understand why and avoid them. And when you get better you will know when rules don’t apply.

Saying “it is not allowed to do X” without explanation is very bad leadership.

Improve this answer
1

You must log in to answer this question.

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