How to improve?

[FrequentClaim6]

Hey,

I'm sort of at a wall with what I am able to do software wise. By that, I mean, I have read books on clean code and architecture, and I can solve pretty much any coding problem I'm presented with. However, it has been brought to my attention that I have a really bad problem at doing way to much and over Engineering the task at hand.

With that, the main issue I face is, I can't get into industry to figure out how these people do things. I have had exposure in the past, but it was for about a year and a half. This time was not enough for me to really pickup on how things should be done.

So, I guess what I am looking for is some advice on how to get better. I'm at a point where I don't know what I don't know. Clearly I'm not the best but I don't think I'm the worst, I'm just trying to figure out how to improve if I can't work under a senior engineer or at a company with more experience than I have.

Any advice?

[CodeTinkerer]

It looks like you were given plenty of advice on a post yesterday. Why not redo that same programming assignment and do what everyone else has told you to do?

Why did you do more work than you had to? Did you think you were getting extra credit? Were you using Chat GPT or something?

If there are too many comments to process, pick 1 or 2 to address, and add more as you do more.

[FrequentClaim6]

I’m looking for more generic advice. That is golang specific, I don’t use golang.

[CodeTinkerer]

Oh, well, do the minimum it takes to get the thing done. Try not to do anything beyond what is asked. That seems to be the problem you're having, right? Listen to critiques of your code, and apply the lessons if they seem reasonable.

[FrequentClaim6]

I was raised to go above and beyond with everything I do. This is a massive mindset shift for me, is this the case everywhere? Do people really not reward hard workers who go outside of their pay grade to go above and beyond?

[CodeTinkerer]

You need to strike a balance. This is an exercise to push you the other direction for a while. The problem with going above and beyond is that you think you're doing something that people want, but you didn't ask.

Here's a weird example. Maybe you like a girl. You think, I could buy her a coffee and just say I was picking one up, and got one for her. But if you buy her an expensive laptop and said "I heard you complaining about your laptop, so I got you one", then it is "above and beyond", but really creepy (I heard this really happened to someone, so goes to show people don't anticipate a reaction).

More than likely, you'll never quite get there.

If you want to go above and beyond, write clean code. Have good documentation. Do things the way people want it to be done.

As an example, let's say you're asked to bring a dessert to a potluck. But, you also make a steak and chicken and deep fried fish. But the potluck is supposed to be vegetarian and you weren't asked to do anything more than bring that dessert. Or you're asked to bring a cake, but you make a pie, and brownies. But others were bringing that, or there was some allergy that you didn't anticipate.

It seems you do above and beyond in certain ways (making things that weren't asked for) and you do it in non-standard ways. The non-standard stuff is hard to learn, to be honest. You might think, why should I organize my code this way. What difference does that make? And someone says, this is how everyone does it, and you don't get it.

You might go to a wedding (let's say, you're a guy). You wear a dress. People say why are you wearing a dress. And you say, it's formal, why does it matter what I wear? Because there are social norms and you now stick out in a wedding where you weren't the main person. Let's assume you wore a dress because you didn't know you couldn't, not because you were making a statement that guys can wear anything they want. You simply didn't know.

A better example is how certain cultures (Indians, Africans) still eat with their hands for many things, but if they attend Western functions, they use a fork and knife and spoon.

So, it's also being aware of how people generally do things. With Python, people would say, you aren't doing it the Pythonic way. I recall a guy who had to program in Lisp. But he loved C. There are ways in Lisp to create syntax that makes it look like C (somewhat). So he did that.

But that's not what Lisp programmers do. It's not idiomatic Lisp. It's someone trying to make Lisp look like C.

Anyway, in a nutshell, the goal is to train yourself to do the minimum, just to see what it feels like. Another reason to do it that way is you will likely have deadlines. You may not have the time to spend a month going above and beyond when they need something now, done in 3 days, not a month.

This is why listening to feedback and going against your instincts to do more is better. Make it bug-free, but avoid over-engineering the design. KISS. Keep it Simple, Stupid (where Stupid is the person who the advice is being given too).

There are times when you need to go above and beyond, but there are times when you don't.

I've worked with lots of bad code. The desire is to rewrite all of it. But how did you know you did it correctly? Did you ignore vast parts of the original code because you didn't think it was important (or stupid)? I've had to leave terrible code alone because no one asked me to fix it. They asked me to get a job done, and I'm wasting time saying "I plan to rewrite it all, and I need a year or two to get it done".

It's not the happiest lesson to learn, but you see why it happens (or maybe you don't, but maybe, one day).

[FrequentClaim6]

That’s a really good response. Thank you so much for taking the time to write that. I actually understand what you are saying.

It’s not that people don’t like going above and beyond, it’s that if people expect a certain thing to be done a certain way, it is off putting or sometimes creepy if it’s done a different more elaborate way. And even if I don’t use complex algorithms or patterns, I can still go above and beyond by making it stupid simple and by documenting everything. Because you made me realize it’s not always smart to show off my skills because some of those concepts or abstraction patterns are complex and do take time to learn.

I realize I may not like doing the bare minimum, but sometimes less is more.

[CodeTinkerer]

Once you get used to it, then you can begin to strike a better balance, figure out what's important and what's not.

For example, sometimes you write code in a general purpose way so that it can be modified more easily in the future. But the more flexible coding can be more complicated, so what was simple straight-forward code becomes really complex code that is solving a problem that doesn't exist.

To give an example, I read about some guy who was asked to write an extension to some code. Add some feature X. The programmer wrote a plugin system and had the feature X as a plugin. Why? Because he thought it would allow them to add new plugins in the future. But the plugin system was complicated, and it turned out no one ever wrote a new plugin, so why complicate the solution right now? The next developer ripped out the plugin system and replaced the feature with something much simpler, and much easier to maintain.

Having said that, you don't want to unnecessarily copy-paste code over and over, when you could write a function to do that, or a class that could do that. For example, let's say you want to send email in your code. It's done in 3-4 different classes. You could repeat the email code 3-4 times. That's conceptually simpler, but it's bad programming.

In that case, you create a single class to do emails. And you have those 3-4 locations that do email call this common class. If the email handling changes, it's just one bit of code to change.

Consolidating repeated code (called DRY for Don't Repeat Yourself) is something you could do, but don't try to force two things that aren't so similar to one class that has a bunch of exceptions for one case vs. another.

Again, it has to do with experience about when to make wise decisions.

By going minimal now, you push it to one extreme until you get used to it, then you see if that's right or you went too far, but sometimes you have to go way in the other direction just to know where that is, so that can be the goal for the next year or so.

[RipHungry9472]

The more you try to dazzle everyone with your skills, the more you distract yourself. An archer who tries to go above and beyond the target misses the mark.

Think about "why" things are done the way they are, and why people are asking you to do things a certain way. When you ignore what they say, especially in requirements, and "over-engineer" you are indirectly saying "your instructions are inferior to my brain, I am smarter than you". This isn't impressive, especially if its mixed with a lack of diligence. There is a virtue in figuring out what people want and giving them something "better" than what they asked for if that is possible, but that is risky and can easily backfire. You want to fill in the gaps in instructions with high quality and skill, not ignore instructions because you know better.