I’ve been on job interviews where the interviewer writes the equivalent of
char *(*(*a)())() on the whiteboard and asks what it declares.
I usually answer that I could probably figure it out but I’m not going to try.
If we, smart as we are, have to scrunch forehead to decipher a line of code, it’s probably a mistake to have written it that way.
If it’s unclear to you now, it will probably be less clear when you look at it again in six months. Less clear to the engineer who has to fix it after you’ve moved on. That way lies bugs.
Further, if the code relies on an advanced or obscure feature, who says that feature works correctly? It’s probably also a confusing facet of the language for whoever wrote the compiler code. And their interpretation might not match what the standard actually requires. Or how the authors of another compiler interpret it.
Let alone whether you can readily translate your approach into another language. Which is handy.
Sometimes a complicated construct really is the best solution. When it is, write as clear a comment as you can that explains what it does, why it’s correct, and why apparent alternatives wouldn’t have worked.
Don’t write checks on someone else’s account.
One of the quickest ways to damage a relationship is to commit someone else to a task or a deadline without discussing it with them first. Whether it’s promising your spouse will chaperone a field trip, the assault team can rescue the hostages, or the spacecraft is go for launch.
Don’t commit to yes. You need to discuss it with the team. Do commit to that and to when you’ll be back with an answer.
It may ultimately be your decision. But everyone appreciates being consulted and resents being ordered. Be a leader, not a boss. Plus there might be a fundamental reason why what was asked for simply can’t be done, period. That they’d tell you if you ask.
Of course, you also need to be someone they feel safe to tell the truth to, and want to.
I realized at some point that I am at core an engineer. Other things too. But I, engineer. I engineer. Aye, engineer!
Later that the maxims I apply on the job are useful throughout life.
I think I’ve learned a bit worth sharing. In my own exploits, and from the great engineers I’ve known as colleagues, friends, or family. (We’ve been at it for four generations so far, starting in 1928. Computers since 1946. I’ll get into the backstory later.)
I’ll delve into minutiae when it matters. It often does. While the specifics are apt to relate to software engineering, you shouldn’t need a background in either software or engineering to get my point.
Of course, sometimes we’re in the weeds to discuss weeds. If your mind wanders, stick around. We’ll be back to interesting soon enough.
You’re invited to opine too. This should be a conversation among colleagues. But read the comment guidelines before you do.