Lessons I Learned From Working on Real Projects

It’s understandable if you find this point common sense. But, you know what? Common sense ain’t common sense sometimes! Let’s 1, 2 .. 5 them.

1. Business Domain

These days we have uncountable frameworks, libraries, open-source software, vibrant communities, and others.

And that’s great.

But, these things are not the goals by themselves. They are tools. They are designed so we can solve some problems. The thing that happens sometimes is people get too focused on them. Why? The tool is made to accomplish something. What have you done with it?

The first time our CTO explained our next project to me — how the customers are using EXCEL and we will be digitizing the requirement into a usable web application and adding monitoring to what they are doing daily — I thought that is cool! Seriously. And he gave me 21 excel sheets and let me wonder about the database design and stuff.

Getting into what problem you are solving in the outer business domain gives you the power because you are engaging fully and whenever a new requirement change is introduced, you can analyze it watching out if it fits with the full picture.

Even if working in big organizations where you are not exactly working on the product as a whole, at least know how the specific part you are building fits with the overall picture. Michael Geers calls this “self-identifying” with the product.

So are you saying, ditch everything and go with whatever we want? Of course not!

The world ain’t gonna unfold every time a new ‘that’ framework or tool comes up. Just don’t be passionate about everything. It’s just another thing with additional utilities.

Obviously, tools have advantages over others. Some are helpful. But don’t just stop being excited too much there. Users are interested in what problem specifically got solved for them — not the framework the team used.

Your technical skill must be interpreted in a way that solves real-life problems.

In my opinion, getting software “right” is a weird intersection of technical know-how, business savvy, creative thinking, communication, and complexity reduction/management.

Some oversimplify the subject as choosing between the white hammer and the blue one. Do tools matter? They really do. But just don’t stop there.

In a nutshell, being the president should not be the goal — rather it’s the path. It’s what you do with it. You don’t just sit there and get a sense of accomplishment of being a president. It’s a path to achieve what you are being voted for. Education is not a goal, it’s a path to serve based on what you have learned. In religion, prayer is not a goal by itself. It’s a path to connect with God.

I’m going a bit far I guess and the topic by itself can be a series of articles so let’s stop here.

2. Communicating With Non-Technical People

Once the project manager came out to me and asked for a list of some users from a specific company registered on our database. I began to write a bunch of SQL statements (it was PostgreSQL) and told him to give me some minutes.

The contact person from the company called him and said it was urgent. He came again and checked my progress, while he left the person with this info over the phone:

“I am contacting the technical team to extract the data. We are almost done and will get back to you.”

Not exactly but he gave such kind of response.

Oh my, it felt so weird the first time. I thought, “Seriously? Dude, what the hell technical team? I am the only one and this is a simple SQL statement!”

Later on, I thought about it and wondered about the idea, ending up examining myself and realized I had gone way informal.

Come on, what was I thinking? Should he have said:

“Since the data is stored in PostgreSQL database, the developer is writing an SQL query by joining the tables to get the data...”

Imagine this for a person who probably does not have the know-how of what databases are in the first place. Weird.

Our project manager was right and after that day, I think I learned to be more formal in my communication while working with non-technical people. Overwhelming them with jargon they don’t need to hear is nonsense.

Dear programmers, you can call this abstraction.

This might also come from the work environment. If you are working with your friends, the way of communication might be way informal and whenever you want to fix bugs, insert an additional feature, or add another requirement, you just say:

“Hey man, that thing we resolved days ago. Remember? It came again.”

Such a communication style affects the formality when trying to work in an environment filled with non-developer peers. Instead of creating a ticket or flagging it on any project management tool, trying to resolve things verbally will make you run out of control.

So? Communicate professionally with people outside the niche.

3. Focus on the Basic Principles

Whilst using any of the tools out there, you might notice the principles do not change. Writing maintainable components, performance optimization, DRY (Don’t Repeat Yourself), WET (Write Everything Twice), AHA (Avoid Hasty Abstraction), UHU, EHI… you name it… are always there.

Sometimes, customers raise good questions. They also guide you on what's important.

“What do you want?”
“I want fast, responsive, reliable software.”

Then you start thinking about how to optimize, test, and be fault-tolerant. And you go for which library is suitable for such purpose, which external service can be integrated into your system… and so on.

Among the reasons I like books even if they are outdated: I can cope with syntax changes which lack backward compatibility in a day or two. But as far as the principles are at hand… we’re good.

4. Burnout Doesn’t Necessarily Need a Long Time

Burnout is:

a natural condition that may be caused by many things, including complex coding sessions, too much work, and tight deadlines.

Let me customize the definition a bit.

If you are exposed to an environment with tight deadlines and lots of unknowns, your mind does not need a prolonged period before it shuts down. I have experienced it and seen others also.

The antidote to this is early communication. We all know deadlines are too optimistic in the industry and someone might promise the moon on your behalf. So whenever you feel like the given time is not enough, speaking up is a good option.

5. Don’t Hate Your Imposter Syndrome

Finally, this might sound cliché. But, as far as it keeps you humble and does not stop you from what you want to pursue and achieve, it’s not that bad. The feeling of not being good enough might force you to read more, explore in-depth, and listen to what others have to say too.

Come on. Anyhow, most developers seem to have this good problem — embrace it, my friend.

PS: Thanks for stopping by. Stay fine :)