we are mantro digital
and we deliver technological impact

Never be too proud to admit a change in your opinion. The world changes, constantly, and sometimes faster than we want. Things once established fade away and new paradigm shifts linger around the corner. Don't fall for analysis paralysis, but also question your beloved tools and practices from time to time. Discuss them, question them, reestablish them, or throw them away. The important part is to make it a reflected endeavour.

Every product brings different challenges to solve. In the most cases a brilliant login dialog does not solve anything. But if you try to establish a new open id service, it might very well be. Think about the 1-5 core problems you will be facing (in terms of complexity and effort). These are the parts which demand good architecture and solutions. Again, a login dialog might be refurbished quite quickly. A tax logic probably not.

Every team member should have roughly the same thought model about how things work in the product. Using the same (high level) words helps a lot. Identifying the CPPs helps a lot. Ultimately you should be able to pitch the inner workings of the product clearly while drinking coffee. Even though eventually your product might go "rocket science", the thought model should still be easy to understand.

Your product is living in a domain. Which might have restrictions, culture, trained behaviours and certain expectations. It is a huge difference if you want to introduce an internal QA tool in a steel-mill or if you are developing a hardcore MMORPG Asia grinder. Understand your context and understand that some of your assumptions might be horribly wrong. Embrace the differences and learn their effects.

"WTF? You don’t have 98% coverage?“. Yep, I actually have 0%. Main reason for that is that I don’t have tests.

Sounds familiar? Well, sorry to break the news. Both are wrong, and right. Actually it depends on the maturity of the product. Early stage? Maybe don't focus on tests, iterate instead. Late Stage? Well, you better have good tests. Always understand that something might not be important right now… but maybe in the not-to-distant future?

Yes vs. no, right vs. wrong, absolute vs. relative. More often than not things are not digital. Although sometimes you have to make extreme calls between technologies (frameworks, methods, etc.), it is more of a judgement call. Get rid of simple dimensions, the reality is very colo(u)rful. A tool might be perfect in one occasion, but horribly wrong in another.

Darn, an exception. Why did this happen? This is not good. It should not fail. Let’s catch it. Maybe log it. Well, probably not a problem, let’s move on.

A perfect solution for your local one-man-show tool. A disaster for your backup cronjob. If you can handle only state 1-3, throw an exception with a meaningful message on all other states. Throw in your name, the class, the method and why you cannot proceed anymore.

This for loop iterates through all "keys" of "array". Great job. You wrote a comment. Clap clap, Captain Obvious. If you write good code, you don't have to comment what it does line-by-line. Focus on the exceptions to the rule, the extraordinary, the hack you had to introduce because of a weird DOM behavior in FF < 39. Explain yourself. Write your name. Add StackOverflow links. Don't hide, you probably had your reasons. Give others the possibility to understand, even if future readers might have a better solution for it.

But the folks at FAANG always use Uranium powered docker containers from outer space?

Well, great. Thing is, I'm out of Uranium and I've never been to outer space. Some companies in the valley (and elsewhere) are operating outside of the normal scale. It's ok to read carefully about their operations and learn, it's ok to think about aspects you can extract form these learnings and put to good use in your own product. But don't cargo cult blindly, especially if you don't have Uranium at your disposal.

Erm, our deployment dudette is on 4 weeks vacation. No releases in that time.

That sounds bad. Very bad. We should design systems in a way that we can rely on safeguards. That the process is understandable. That the necessary things are documented. And everybody needs to be able to execute crucial steps. Be it deployment, or bugfixing. Deploy often. Get rid of the fear. Get used to it. Mistakes will be made, shit will hit the fan, yadda yadda. Step up and do it yourself. With the help of others. With supervision. And then, without safety net. Yourself.

I don’t know who wrote that code, I have nothing to do with it. The guy left a month ago.

This is a very common sentence... in a corporate. You should never find yourself in that situation. Take ownership of what you do. Somebody is leaving? Ask them for a handover, check out the code, read into it. You think somebody is about to do a bad decision? Speak your mind, explain why you see negative implications. You see parts of the code breaking? Come up with a plan on how to tackle it.