!rant

So, my company already has subscriptions to rally (jira alternative) but the current team fucking uses an online SPREADSHEET to track work items! it's easy to track, blah blah, fuck you. The feature requirement is just one fucking line long. Are you kidding me. Don't come back to me saying something is not working as expected when you didn't specify how it should work.

Why most of the Indian developers code so bad? I face it very often, with my colleagues, with the freelancers we hire, even with our clients.

I am an Indian, and I feel so much disgusted (& sad as well) when a client tell us that they have a dedicated team to rework on the code which they outsource from India. If you visit a freelancing website you will see that the Indian developers have the least price, and they bid on literally anything even without understanding what they need to do. And finally when they get a job, they complete it, but with a fully f*cked up code and the worst architecture possible.

I have a lot of friends working in IT, and I personally know that they do not have any passion about programming. They just work for money, nothing else. I don't understand, why? My 7 years of IT career is probably not long enough to find a suitable answer for this 'why'.

!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!

"A different error message! Finally some progress!"

fuck you fucking Indian programmers, how it is possible that you are so fucking messy to code?, why can't you have some decency and write some readable code!, for fucks sake!

What really grind my gears, is that 90% of the project is built with dynamic Javascript, WTF????

Every component for every page is done in javascript while loading, seriously?, there wasn't a better way to do it? -.-

And SQL... oh dear fucking GOD!, I mean, how am I supposed to understand your code if you can't even use some alignment with TABS or spaces.

Better go to my lunch break so I can rethink my work to do tonight :(

Looking at code in our workplace.. I realized one thing. Like Devops, legacy code is actually a mindset.

So here goes my thought:

A piece of code is not legacy because it was written ten years ago.

A piece of code is legacy because it looks like a piece of legacy code.

With the legacy code mindset, you end up writing legacy code no matter where you are, when you wrote it.

I was looking at some part of our code which we written in just the last few months, and I can’t help but think that they were legacy, so it really doesn’t matter when it was written!

It is more about how you write your code that determines whether it is legacy :)

Hopefully this was not crazily confusing anyone. Have a good day guys & gals!