4 ms·

"Coding is the easy part" Yes...but, only for really good engineers.

wccrawford 8y ago
I disagree. For bad engineers, coding is still easier than figuring out the solution to the problem, even if they find coding really hard.
- daveFNbuck 8y ago
  It's usually easy to figure out a bad or incomplete solution that is difficult to code.
  - wccrawford 8y ago
    Are you saying that it's okay for junior developers to develop non-acceptable solutions? Because it's not okay in my book. Figuring out how to design half of a system isn't anything. Anyone can do that. Non-programmers do that all the time. Engineering a solution means the whole thing, not just the easy parts of it, just like coding the solution means coding the whole things, not just the easy parts of it.
    - daveFNbuck 8y ago
      I'm saying that inexperience and bad design add to the difficulty of coding.
    - daveFNbuck 8y ago
      I'm not saying it's ok, just that people often have more trouble with coding than finding a solution because bad solutions can be easy to find but hard to code.
piotrkubisa 8y ago
I also disagree, coding is the easy part. When you are junior not everyone requires from you to be know-it-all person nor providing super-good quality code, especially in your first months of journey in the company codebase. However, almost anyone wants to notice a "fresh air" and a person who shares his/her commitment in various form starting from the day one. Edit: Hey, it is easy to implement code having bugs (shortly: implement bugs) and do many fixes further. It is hard to understand the problem and write code once, which won't need any bugfix. Think about the Apollo-11 code [0] - one tiny bug and astronauts might be dead. [0]: https://github.com/chrislgarry/Apollo-11 https://github.com/chrislgarry/Apollo-11
- yakshaving_jgt 8y ago
  Do you think they hired juniors to work on the Apollo 11 code?
  - piotrkubisa 8y ago
    No, definitely not. I took that example to provide you a real life example of software which cannot be "fixed in production" what is very known type of fixing code these days. If you do understand the problem you really can bring that quality of code which does not need any bugfix during it's run-time. As I written in second sentence: almost nobody wants from you providing that quality of code starting at day one.
InclinedPlane 8y ago
I've been reading other devs code for about two decades now. Universally all the code I see is not quite up to the standards I have for "good code" though some of it is better than others. Most devs give up on getting better writing code too easily, or more importantly they focus on the wrong things. There is always room for improvement no matter how good you are. Focus on making your code clearer, not fancier or "faster". Don't prematurely optimize your code by eye. Generally just being conscious of the major performance no-nos to avoid and being able to use appropriate tools (like a profiler) when and if you actually need to tune performance is all you need. Instead concentrate on making your code highly readable, self-documenting plus fully documented (the best of both worlds!), as well as composable and maintainable and you'll be well set. Not just will you make other developers happy and improve the code base overall (fewer bugs, easier modifications for inevitable feature changes in the future) but you'll make your future self happier when you have to come back to that code. By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people, it's not that hard and it's a great habit to get into. It takes skill to get good at it but a decently named small function makes code more readable and more reliable. And getting into the habit of making little functions that just take a few inputs, do stuff, and return a value makes your code way easier to unit test as well.
- Kabootit 8y ago
  > Focus on making your code clearer, not fancier or "faster". Exactly! > By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people As a general rule this is just one side of the coin imo. I often see this approach increasing the complexity of control flow in direct proportion to the simplification of individual code blocks. Net gain zero.
- badpun 8y ago
  > Extract your methods people, it's not that hard and it's a great habit to get into. It takes skill to get good at it but a decently named small function makes code more readable and more reliable. For me it actually makes code less readable. It makes the system more complex (because you've added extra function definitions and function calls) and just jumping back-and-forth between those small function calls makes code harder to read. I would much prefer to have a larger method that just does things in order, and, for readability, have its body divided into sections, each in isolated brackets (so that variables have local scope) and commented if necessary.

I disagree. For bad engineers, coding is still easier than figuring out the solution to the problem, even if they find coding really hard.

daveFNbuck 8y ago
It's usually easy to figure out a bad or incomplete solution that is difficult to code.
- wccrawford 8y ago
  Are you saying that it's okay for junior developers to develop non-acceptable solutions? Because it's not okay in my book. Figuring out how to design half of a system isn't anything. Anyone can do that. Non-programmers do that all the time. Engineering a solution means the whole thing, not just the easy parts of it, just like coding the solution means coding the whole things, not just the easy parts of it.
  - daveFNbuck 8y ago
    I'm saying that inexperience and bad design add to the difficulty of coding.
  - daveFNbuck 8y ago
    I'm not saying it's ok, just that people often have more trouble with coding than finding a solution because bad solutions can be easy to find but hard to code.

piotrkubisa 8y ago

I also disagree, coding is the easy part. When you are junior not everyone requires from you to be know-it-all person nor providing super-good quality code, especially in your first months of journey in the company codebase. However, almost anyone wants to notice a "fresh air" and a person who shares his/her commitment in various form starting from the day one. Edit: Hey, it is easy to implement code having bugs (shortly: implement bugs) and do many fixes further. It is hard to understand the problem and write code once, which won't need any bugfix. Think about the Apollo-11 code [0] - one tiny bug and astronauts might be dead. [0]: https://github.com/chrislgarry/Apollo-11 https://github.com/chrislgarry/Apollo-11

yakshaving_jgt 8y ago
Do you think they hired juniors to work on the Apollo 11 code?
- piotrkubisa 8y ago
  No, definitely not. I took that example to provide you a real life example of software which cannot be "fixed in production" what is very known type of fixing code these days. If you do understand the problem you really can bring that quality of code which does not need any bugfix during it's run-time. As I written in second sentence: almost nobody wants from you providing that quality of code starting at day one.

InclinedPlane 8y ago

I've been reading other devs code for about two decades now. Universally all the code I see is not quite up to the standards I have for "good code" though some of it is better than others. Most devs give up on getting better writing code too easily, or more importantly they focus on the wrong things. There is always room for improvement no matter how good you are. Focus on making your code clearer, not fancier or "faster". Don't prematurely optimize your code by eye. Generally just being conscious of the major performance no-nos to avoid and being able to use appropriate tools (like a profiler) when and if you actually need to tune performance is all you need. Instead concentrate on making your code highly readable, self-documenting plus fully documented (the best of both worlds!), as well as composable and maintainable and you'll be well set. Not just will you make other developers happy and improve the code base overall (fewer bugs, easier modifications for inevitable feature changes in the future) but you'll make your future self happier when you have to come back to that code. By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people, it's not that hard and it's a great habit to get into. It takes skill to get good at it but a decently named small function makes code more readable and more reliable. And getting into the habit of making little functions that just take a few inputs, do stuff, and return a value makes your code way easier to unit test as well.

Kabootit 8y ago
> Focus on making your code clearer, not fancier or "faster". Exactly! > By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people As a general rule this is just one side of the coin imo. I often see this approach increasing the complexity of control flow in direct proportion to the simplification of individual code blocks. Net gain zero.
badpun 8y ago
> Extract your methods people, it's not that hard and it's a great habit to get into. It takes skill to get good at it but a decently named small function makes code more readable and more reliable. For me it actually makes code less readable. It makes the system more complex (because you've added extra function definitions and function calls) and just jumping back-and-forth between those small function calls makes code harder to read. I would much prefer to have a larger method that just does things in order, and, for readability, have its body divided into sections, each in isolated brackets (so that variables have local scope) and commented if necessary.