4 ms·

I just write simple code and it becomes very maintainable and easy to understand for anyone. In my opinion, it's people who have the need to abstract away ever

I just write simple code and it becomes very maintainable and easy to understand for anyone. In my opinion, it's people who have the need to abstract away everything who complicates the code bases. Give me simple, elegant code that doesn't complicate what the program does, and you have maintainable code that can be changed and deleted easily.

hinkley 5y ago
Used to be, if you didn’t know what else to look for when interviewing people, you’d pick the person who communicated clearly. Because if they’re wrong at least you know quickly, instead of them secretly making a mess for a long time before you figure it out.
keyle 5y ago
I completely agree with this, but this has little to do with the comment you're replying to. Simple dumb code, unless absolutely needed to be "fast and smart", should be the defacto standard. Which is why Go is so good as an enterprise language. Its very design is a standard for maintainability.
interactivecode 5y ago
Everyone always talking about simple code. But what can we agree on that makes code simple?
- Benjammer 5y ago
  SOLID[0] is always somewhere to start if you really have no idea where to begin understanding what makes code more maintainable. There are plenty of books out there, but those can be a minefield in terms of knowing which ones to really commit energy to learning. The only real answer that I know of here is personal experience though. [0]: https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID
Terry_Roll 5y ago
That maybe the case, but your inexperience shows, namely because different programmers have different styles or ways of doing things, so on a big system which has had numerous programmers working on it, in the absence of management installing a design & coding guide, you will end up with a can of worms! So how many ways could you come up with that accesses data in a file? You have an OOP filemanager class which can handle CRUD to ISAM and RDBMS (SQL) back ends, the windows API's both to disk files and ODBC if the RDBMS doesnt have its own library. If you dont check and enforce basics like this, you will get eloquent functional code that meets the remit but doesnt fit into the app, eg some procedures which read and write to a file using win32 apis but ignores the OOP filemanager that exists and then the OOP filemanager class doesnt know what files are open on what thread. The problem here is management didnt have any rule book for the basics, they also couldnt or didnt want to pay for someone else to look over the code to ensure standards/rules were being met. And then businesses wonder why their apps gets pwned so easily? Shareholders dont always learn because they dont fire the board who presided over such fubars either. And so the cycle repeats.
GuB-42 5y ago
I have worked with "simple" code. It was a terrible but interesting experience. The main developer was an old mechanical engineer who learned coding by himself. And to be simple, his code was simple. There was a GUI with a 7x8 table of numbers. How to do this? 54 text fields, all with their own name with copy pasted initialization. Most variables were global, no class hierarchy, no fancy algorithms, juste nested loops, etc... Because it was so straightforward, it was surprisingly easy to understand despite its complete disregard of any methodology. If it has to do A, you will see A, no surprise action at a distance, and if it has to do A ten times, you will see AAAAAAAAAA. But maintaining it is as bad as it may seem, and if you have to change A to B, you will need to change all ten of them, being careful that they may be slightly different, and forget about parallelism, security, undo, etc... So yes, simple code is simple, but without at least some level of abstraction it will soon end up being terrible. What is too much or too little abstraction? Just hire a few world class developers and give them as much time as they need, because it may be the most difficult question a developer has to answer. In fact, one could argue that the mythical "10x developer" is one who answers right.
- Rexxar 5y ago
  > There was a GUI with a 7x8 table of numbers. How to do this? 54 text fields Sorry, I have to fix this : 56
  - Roboprog 5y ago
    Maybe there were only 54, and that was one of the bugs to be fixed - exactly the sort of problem that lurks in that kind of repetitive code.
908B64B197 5y ago
One of the issues is also that code that's trivial for John Carmack to understand might not be for $BODY_SHOP_RESSOURCE_200353. I recall a self taught dev (or maybe from a bootcamp) coming up with a cascade of nested if-else, nested 8 deep. Someone with a background in CS asked him what he was trying to do and basically concluded that what he was trying to do could be expressed as a state machine. To which the initial dev replied that it was "way too fancy" and that he didn't need the code to be fancy, just work.
- rmbyrro 5y ago
  Not a counter to what you said, but just adding a point that might be worth thinking: This way of telling may give impression you are inplying that CS graduates know patterns and self-taughts don't. You will certainly find self-taught who know Finite-state Machine very well, and CS graduates that might have heard but can't identify where to use nor how to implement.

hinkley 5y ago

Used to be, if you didn’t know what else to look for when interviewing people, you’d pick the person who communicated clearly. Because if they’re wrong at least you know quickly, instead of them secretly making a mess for a long time before you figure it out.

keyle 5y ago

I completely agree with this, but this has little to do with the comment you're replying to. Simple dumb code, unless absolutely needed to be "fast and smart", should be the defacto standard. Which is why Go is so good as an enterprise language. Its very design is a standard for maintainability.

interactivecode 5y ago

Everyone always talking about simple code. But what can we agree on that makes code simple?

Benjammer 5y ago
SOLID[0] is always somewhere to start if you really have no idea where to begin understanding what makes code more maintainable. There are plenty of books out there, but those can be a minefield in terms of knowing which ones to really commit energy to learning. The only real answer that I know of here is personal experience though. [0]: https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID

Terry_Roll 5y ago

That maybe the case, but your inexperience shows, namely because different programmers have different styles or ways of doing things, so on a big system which has had numerous programmers working on it, in the absence of management installing a design & coding guide, you will end up with a can of worms! So how many ways could you come up with that accesses data in a file? You have an OOP filemanager class which can handle CRUD to ISAM and RDBMS (SQL) back ends, the windows API's both to disk files and ODBC if the RDBMS doesnt have its own library. If you dont check and enforce basics like this, you will get eloquent functional code that meets the remit but doesnt fit into the app, eg some procedures which read and write to a file using win32 apis but ignores the OOP filemanager that exists and then the OOP filemanager class doesnt know what files are open on what thread. The problem here is management didnt have any rule book for the basics, they also couldnt or didnt want to pay for someone else to look over the code to ensure standards/rules were being met. And then businesses wonder why their apps gets pwned so easily? Shareholders dont always learn because they dont fire the board who presided over such fubars either. And so the cycle repeats.

GuB-42 5y ago

I have worked with "simple" code. It was a terrible but interesting experience. The main developer was an old mechanical engineer who learned coding by himself. And to be simple, his code was simple. There was a GUI with a 7x8 table of numbers. How to do this? 54 text fields, all with their own name with copy pasted initialization. Most variables were global, no class hierarchy, no fancy algorithms, juste nested loops, etc... Because it was so straightforward, it was surprisingly easy to understand despite its complete disregard of any methodology. If it has to do A, you will see A, no surprise action at a distance, and if it has to do A ten times, you will see AAAAAAAAAA. But maintaining it is as bad as it may seem, and if you have to change A to B, you will need to change all ten of them, being careful that they may be slightly different, and forget about parallelism, security, undo, etc... So yes, simple code is simple, but without at least some level of abstraction it will soon end up being terrible. What is too much or too little abstraction? Just hire a few world class developers and give them as much time as they need, because it may be the most difficult question a developer has to answer. In fact, one could argue that the mythical "10x developer" is one who answers right.

Rexxar 5y ago
> There was a GUI with a 7x8 table of numbers. How to do this? 54 text fields Sorry, I have to fix this : 56
- Roboprog 5y ago
  Maybe there were only 54, and that was one of the bugs to be fixed - exactly the sort of problem that lurks in that kind of repetitive code.

908B64B197 5y ago

One of the issues is also that code that's trivial for John Carmack to understand might not be for $BODY_SHOP_RESSOURCE_200353. I recall a self taught dev (or maybe from a bootcamp) coming up with a cascade of nested if-else, nested 8 deep. Someone with a background in CS asked him what he was trying to do and basically concluded that what he was trying to do could be expressed as a state machine. To which the initial dev replied that it was "way too fancy" and that he didn't need the code to be fancy, just work.

rmbyrro 5y ago
Not a counter to what you said, but just adding a point that might be worth thinking: This way of telling may give impression you are inplying that CS graduates know patterns and self-taughts don't. You will certainly find self-taught who know Finite-state Machine very well, and CS graduates that might have heard but can't identify where to use nor how to implement.