3 years ago I got my first job as software engineer, there is a huge difference between writing university projects and shipping real working software, I learnt a lot of things that forged my mind.
I started from writing little features and end up to bigger ones. Step by step I found patterns better then others, and learn how to write better quality code.
I dealt with different kind of software, written by fellow juniors and seniors engineers and I saw different approaches about dealing with problems.
A great junior engineer is very idealistic, he wants to write very clean code with blending edge tools. He spots a lot of troubles or bad practices on already written production code and wants to rewrite everything to make it better.
A senior engineer has written a lot of software, he agrees with the junior about bad written code but does not want to change it, because it works. A junior developer hates this word but it’s true. If something works, you don’t need to waste your time changing it, and the best explanation I’ve read is this:
“Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.” Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive.
Quote from Joel Spolsky
So do we have to stay always with the same software because it works? I did two rewrite on my career, one succeeded and one not. Why? My answer now is that you need to rewrite if your software does not fit your scenario anymore: does not scale, cannot provide more features or whatever. There is a subtle balance between the bug shower you will get and the gain you will accomplish with your change. If it’s worth to do it, you will succeed, if it’s not worth you will probably fail.
A senior engineer has worked with a bunch of technologies. Sometimes it’s a trap, because he tends to deal with a problem using always the same tools, sometimes they are still good, sometimes not.
A junior engineer has a great quality: he knows nothing. He sees problems for the first time and he can find solutions from a different angle that experienced engineers don’t find. Junior engineers are amazed by new tools of any kind: languages, databases, frameworks etc.
Listening to them can led your project to new levels, fighting the attitude of staying inside the well known circle.
When comes to a new project a junior engineer starts to write everything from scratch. Seniors instead tends to start from a similar tool and modify it to fullfill required needs. Why?
The main problem is that reading software is harder than writing it, junior finds hard to read software written by others and so he prefers to start from scratch.
I learnt that any production software is always bad, it has some bad practices, 1000 lines of code functions, uses a database not good for the scope and more. This because when you begin a project it’s like starting a journey without knowing the destination. Software it’s like a sculpture, you start from a blank screen and begin to engraving your code. You discover step by step what your software should do and you can’t start again from scratch at any change.
The difference between a good software and a bad one is that a well written software is easier to change even if it has some bad practices inside.
Copyright © 2014-2016 Luca Marturana. License.