Why do product managers think their roadmaps/decisions are completely unrelated to our technical decisions? Information/transparency are key themes in the architecture process. In order to accept the risks, you must first understand them.

!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

Me: So here's the completed website.

Client: *goes to Google and searches for media agencies india* What the hell is this ? I was told that my name would come on the first page in Google.

Me: Sir, we had quoted to build SEO friendly pages and not for doing SEO.

Client: This is fraud. How the hell could you cheat me by using these technical words. I want my name on the first page in Google.

Me: *types companyname.com in Google* Here Sir, your website is on the first page in Google.

Client: I very well know fraudsters like you. If I wouldn't have checked it then you'd have charged me for this later on. Here's your cheque.

Worst part of being a dev is handling less techy people than you 😫

Me: What do you want?
Client: We don't know exactly
Me: By when do you want it?
Client: Yesterday
🙊🙉🙈

You might know by now that India demonetized old higher value notes and brought in new one. The new ones easily tear off easily and generally feel cheaper and less reliable than pervious ones.

One interesting thing people discovered is that rubbing it with cloth makes the ink transfer to the cloth. Sign of crap printing. Here's government response:
The new currency notes have a security feature called 'intaglio printing'. A genuine currency note can be tested by rubbing it with a cloth; this creates a turbo-electric effect, transferring the ink colour onto the cloth
TL;DR: its not a bug, it's a feature

This rant is aimed towards those who hate on JavaScript developers and the JS language:

Dear Asshole,

I am a JavaScript developer by choice.
I think JavaScript is great.
I agree that JavaScript have some bad sides to it, but I believe that the community is driving good change to the ecosystem.
I appreciate other models of other languages.
I do not include 3rd party NPM modules without checking their source and credibility.
I will not use a framework (i.e. react, Vue, Anguler) if it's not needed.

And finally:
I can do any software engineering tasks a software engineer is supposed to do.

Kind regards,
Nedo-the-angry.

cropped

Who thought teaching jQuery BEFORE JavaScript was a good idea?