DEV Community

Cover image for Software Engineering: The Textbook Omissions
Abhishek S
Abhishek S

Posted on • Edited on • Originally published at blog.abhishekvash.xyz

Software Engineering: The Textbook Omissions

It’s been two years since I emerged as the victor from interview hell. After countless sleepless nights, hours in code reviews, and thousands of lines of code in production, what are my thoughts on this line of work? Is it everything I dreamt of? Yes and no. I love it, and I’ve learned almost everything I know on the job. But it’s not all sunshine and rainbows. The grass is less green than I thought, and the rose tint on my glasses has worn off. Several gotchas almost got me. So, here are some things I wish I had known earlier in my brief experience as a UI engineer.

It’s not just about being good at the technical stuff

You can churn out 10k lines of code a week, have flawless code reviews, and even know everything there is to know (Hey, Sheldon Cooper). But if you're difficult to work with, that's not going to fly. Being a team player and open to collaboration can take you further than going solo.

Image description

Hence, communication is as, if not more, important than code

Facing an approaching deadline or a feature you don’t know how to build? Is there a bug that no matter how much you scratch your brains out, you can’t fix? There’s a high chance that things will work out if you talk about it with your peers/superiors. It's not productive to scour StackOverflow for countless hours all by yourself. People would rather know about issues as soon as possible than get blindsided at the last moment. Bite that bullet and send that Slack dammit.

Communication is also key to efficiency. Good communication helps get ideas across without much hassle. This allows brainstorming to yield more meaningful results. It makes pair programming a fun experience. It makes the workplace a well-oiled machine. Speak out.

Put in a conscious effort towards a work-life balance

It feels so good when you pull in those 30 hours non-stop to get that one feature up and running. It’s immensely gratifying. But before you know it, you’re doing it all the time. And unsurprisingly, you’ve become disconnected. Things you used to like don’t interest you anymore. And you don’t seem to find the time to do them either anyway. And that is a one-way ticket to ‘I hate my job’-ville. You need to make a conscious effort to maintain a work-life balance to ensure both go smoothly. Get yourself some ‘Me’ time. Hang out with your friends and family. Finish that book you’ve left half-read.

So yes, hustle. But hustle responsibly. You don’t want to break down at the age of 25.

Write code for humans, computers can understand it anyway

There are thousands of books and articles on Clean Code practices, that’s how important it is. Code readability takes priority over efficiency. Efficiency cannot come at the cost of spaghetti code. If you can't avoid writing convoluted logic, drop in appropriate code comments. Go a step further to make a document for it.

We created a well-defined coding policy. This helped us put the best practices in place. Peer reviews, peer programming, and maintenance have never been easier. In the end, readability and context matter. Think about the poor chap who has to work on it years down the line (might even end up being you).

And hey, if you work on web UIs like me, who are you kidding thinking about efficiency and performance? I mean come on, it's Javascript.

But you will bury a few bodies

I just told you clean code is important. You watch a ton of YouTube tutorials focusing on how to write the most pristine code. You read a gazillion articles about the correct way of doing things. You now love good engineering, to an extent where it’s intellectual masturbation. But you know what, life ain’t full of unicorns. There are unrealistic deadlines. Realistic expectations. You just need to get shit done. When companies have to choose between well-written software and fast delivery (what is fast delivery? Well this Friday), they often go for speed. Because that’s how businesses work. Sometimes getting something in the hands of customers, even if it's a little shabby, can make or break it. So there is always, however little, technical debt.

So document… everything

Hacked something together for now? Found a cool short way to implement a function off of Stack Overflow? Found a neat niche CSS trick to position that button? Are you using a hardly known edge case library function? Document it. Add good comments. even add a ReadMe with the link to the source. Chances are even you won’t remember it 3 months down the line. And there’s no way another developer jumping into the code would understand it. Have some empathy for future developers (which might include you).

Image description

Remember, a comment should ideally not tell me what is going on. That’s the job of well-named variables, functions and files. A comment should tell me the why and in rare cases, the how.

My Key Takeaway: Find your USP and improve on it

If you take just one thing from this article, it should be this. Every person is different. Each of us has something unique to offer. For some, it may be plain right off the bat, but for some, not so much. Take some time off for yourself and think about it ( caution: existential crisis lies ahead! ) What’s something of value that only you can provide? It might be simple. It might be weird.

I come from a creative background (I’m a musician). And I also seem to have great attention to detail. This helps me build pixel-perfect UIs. I always make an effort to think outside the box and further improve on the intended designs. I always look to empower our designers with ways to make our UIs delightful.

My strengths help elevate our products. It helps me provide value on top of my expected responsibilities. So, find your unique strengths. Work towards integrating it into your daily life. You might see an immediate change in all areas of life, not just work.

Something to figure out: It can get overwhelming

Image description

Software moves really fast (yeah I’m not talking about you, Enterprise). It can get overwhelming trying to keep up with everything. How do you know which hype is real vs. a dud? How do you know if the 2349239th Javascript released today really is, in fact, a game changer? What if you bet on the wrong stack? What if you misjudged something, and have now suddenly, fallen behind? Let me know in the comments.

Top comments (0)