4 ms·

"Attention to Detail" is my major weak point. I don't have it in coding. Give my a philosophical essay, a political discussion or an academic paper and I'll dro

by kharak 8y ago

"Attention to Detail" is my major weak point. I don't have it in coding. Give my a philosophical essay, a political discussion or an academic paper and I'll drown you in details, implications and references. Those come intuitively to me. Writing codes is completely different. I have to practice everything what others seem to do intuitively. I need checklists. I need to take notes. I need to review my task and codes several times. And still, I overlook the obvious and never spot the easiest implementation (even for trivial tasks like checking for empty Strings). All while it takes me a great deal of discipline to take care of the level of detail that is required. If someone here has/had the same problem, I'd like to hear their solutions.

dwrodri 8y ago
Just out of curiosity, is you background in web development and/or the C family of languages (i.e. C, C++, C#)? I mention these because they rely heavily on object-oriented and/or imperative programming paradigms. With C and C++, I still struggle often with striking a good balance between "writing a short solution that works well" and "writing code which is a joy for others to read". The former often relies on my technical knowledge and produces code that can be obscure to other readers, the latter often requires MUCH more concentration and attention to detail when writing. However, I have recently started experimenting with declarative and functional Programming. Coming from an imperative background has made "relearning" how to program quite difficult for me, but I've just started to see the "elegance" in higher level functional languages, such as OcaML and Haskell. Of course, functional languages are often MUCH better suited to different problems than OOP languages, but combining filters, reductions, maps and folds seems to activate the parts of my brain that are much more closely associated with the "classical logic" side of programming. I think you should check it out if you haven't already.
- kharak 8y ago
  You're on to something. I started with database programming, so mostly declarative. That was a joy and I did't need much time to catch up with the senior developers. Afterwards, I switched my employer and started anew with Java. I was completely overwhelmed and struggle to this day. Last week, I learned a little bit about streams and how functional programming works in Java. To my surprise, that seemed quite easy to understand. I don't really know why OOP seems so much harder for me to do.
  - jayar95 8y ago
    If you like the functional aspects of Java, check out kotlin. It's quickly become my favorite programming languages because you get all the benefits of java's strongly typed OOP system with a lot of elegant functional features, and type inference!!
  - mrfredward 8y ago
    Honestly, I thinks it's because a lot of OOP is awkward and forced. When it was the craze, object orientation became an ends instead of a means, and so it taken past the point of being clean and useful. Why do c# and java require every function, including main, be in a class? Why do we need static classes, which are really just a namespace for functions? There's no benefit to the programmer, it only serves the "everything is an object" paradigm. Certain OOP patterns, like the visitor pattern, are really just hacks to make OOP work like functional. I use c# everyday at work and for the most part love it, but there are certain problem domains (anything with significant multithreading) where forced OOP thinking just makes everything harder than it needs to be.
    - james_s_tayler 8y ago
      Curious, can you explain how the visitor pattern is like functional programming? What is it analogous to in FP? It's not a pattern I have ever really wrapped my head around fully, but perhaps there is some structure in functional programming that if I view it through that lens it will make much more sense?
- wool_gather 8y ago
  This was exactly my thought as well: parent might find that a different programming language/paradigm suits their natural thought processes better. Try out a Lisp, maybe, or even something real fun like Prolog. There's still details to be aware of, but they definitely have a different "flavor" that might be more palatable.
addicted 8y ago
I suffer from similar issues. Something that really works against me in the standard coding interviews. Some ways I try to mitigate some of those issues at work are: 1) Peer/senior code reviews. I try and get code reviews done by other folks. This helps with identifying something easy that I may be missing. Usually, once I already have a solution to a problem, I find it hard to revisit it without that solution overwhelming my approach, unless a bit of time has passed. Getting some fresh eyes to look at it helps. Also, explaining the solution to someone else often helps me identify issues with my solution during the process of explaining it to someone else itsel. 2) Practice and experience. I think for the most part intuition is simply the result of experience and practice. 3) Learning different programming paradigms. Something that has helped me more than anything else I think is learning programming languages that cover different paradigms. I’ve never coded anything useful in Haskell, but just the process of solving basic programming problems in Haskell, with its strong functional approach, helps me identify issues with the proceduaral/OOP code which I do write to solve useful problems. I think it allows me to approach each problem from multiple perspectives so even if I don’t have certain Haskell features available to me, it makes it easier to recognize that this may be an issue I need to address in my OOP code (for example, the Haskell compiler when pattern matching requires all possibilities to be addressed. Awareness of this fact means that anytime I’m writing conditionals checking the input I’m much more aware of the fact that I need to also handle the else condition, something that most non-functional programming languages don’t hsually require in their conditional constructs). 4) Related to #3m opting for better solutions wherever possible. I always try and opt for expressions over statements. I try to avoid state change as much as possible. I try and minimize side effects in functions, and try to constrain them in specific areas of code, etc. 5) Formal CS study. I don’t have a CS background, but studying formal CS in my free time has helped a lot. Getting better at data structures, algorithms, formal verification, etc, has helped develop my intuitions even if I don’t sctually use those data structures and formal verification methods in practice.
voidhorse 8y ago
I can speak to this issue as someone who comes from a formal background of philosophy and literature, but whose work involves a lot of programming (both reading and writing code) at this point. Foremost: practice. If you can read and write essays at a college level you've been practicing the craft for (likely) years. Most educated people in the US start engaging with letterforms as soon as kindergarten (!), and no later than 1st grade if not preschool. Contrarily, we don't start so early with the rules of logic nor programming constructs. Most folks don't start programming until much later, and even those who are precocious in this regard usually don't begin using "real" languages (in other words, not stuff like lego robotics or scratch) until they are ~13 or so (of course, there are plenty of exceptions). As with most skills, practice is invaluable. On a conceptual level, I found that making the jump from asking myself what does this code do to what does this code mean majorly beneficial. It may seem like a minuscule or pedantic semantic point, but it actually makes a world of difference. Just like essays, programs are expressing—they are saying something. If you shift from approaching programming from a goal oriented perspective to a communications perspective your code will probably improve immensely. I think this is the reason guys like Donald Knuth stress code readability and literate programming so heavily—at the end of the day, that's what's really important: communicating some idea—just like we do in plain old english. We simply have a broader audience (the latter part of which is very picky about what it understands). The notion of a proposition in logic doesn't do, it means. Programs are essentially a set of propositions which just so happen to have the side effect that they can make a device (a computer) do something when it interprets them. Just as linguistic commands ("go to the store") are "pure" and free of side effects in and of themselves—they only have effects under human interpretation. On a somewhat related note, I find stepping away from programming languages and starting with pen and paper is great. I think people tend to let programming languages get in the way of the real nature of what it is they're doing, which is solving problems in a structured manner, using mathematics and logic (algorithms and data structures). You don't need a programming language to do this, it's only a vehicle to express your solution. Just as you'd often start writing a formal paper by exploring your ideas in an outline or notes, or a couple of first drafts in which you hash things out, you can start "programming" by sketching ideas for solutions and better comprehending the problem at hand. This will ultimately help you write better code. I think a lot of self-taught devs, such as myself, miss this part early on as our entry point into the discipline is often through the languages and tends to kind of remain at the level of the languages we like unless we dig deeper into the underlying formalisms driving them. Too often people just go along with their first-pass understanding of a problem and begin reaching for the libraries, language constructs, etc. that they think they need. Someone with formal training, contrarily, has professors that can help them recognize the concepts behind the languages and connect up and distinguish the notion of a language as a mode of expression and programmatic problem solving as a practice irrespective of the selected language.

by kharak 8y ago

dwrodri 8y ago

Just out of curiosity, is you background in web development and/or the C family of languages (i.e. C, C++, C#)? I mention these because they rely heavily on object-oriented and/or imperative programming paradigms. With C and C++, I still struggle often with striking a good balance between "writing a short solution that works well" and "writing code which is a joy for others to read". The former often relies on my technical knowledge and produces code that can be obscure to other readers, the latter often requires MUCH more concentration and attention to detail when writing. However, I have recently started experimenting with declarative and functional Programming. Coming from an imperative background has made "relearning" how to program quite difficult for me, but I've just started to see the "elegance" in higher level functional languages, such as OcaML and Haskell. Of course, functional languages are often MUCH better suited to different problems than OOP languages, but combining filters, reductions, maps and folds seems to activate the parts of my brain that are much more closely associated with the "classical logic" side of programming. I think you should check it out if you haven't already.

kharak 8y ago
You're on to something. I started with database programming, so mostly declarative. That was a joy and I did't need much time to catch up with the senior developers. Afterwards, I switched my employer and started anew with Java. I was completely overwhelmed and struggle to this day. Last week, I learned a little bit about streams and how functional programming works in Java. To my surprise, that seemed quite easy to understand. I don't really know why OOP seems so much harder for me to do.
- jayar95 8y ago
  If you like the functional aspects of Java, check out kotlin. It's quickly become my favorite programming languages because you get all the benefits of java's strongly typed OOP system with a lot of elegant functional features, and type inference!!
- mrfredward 8y ago
  Honestly, I thinks it's because a lot of OOP is awkward and forced. When it was the craze, object orientation became an ends instead of a means, and so it taken past the point of being clean and useful. Why do c# and java require every function, including main, be in a class? Why do we need static classes, which are really just a namespace for functions? There's no benefit to the programmer, it only serves the "everything is an object" paradigm. Certain OOP patterns, like the visitor pattern, are really just hacks to make OOP work like functional. I use c# everyday at work and for the most part love it, but there are certain problem domains (anything with significant multithreading) where forced OOP thinking just makes everything harder than it needs to be.
  - james_s_tayler 8y ago
    Curious, can you explain how the visitor pattern is like functional programming? What is it analogous to in FP? It's not a pattern I have ever really wrapped my head around fully, but perhaps there is some structure in functional programming that if I view it through that lens it will make much more sense?
wool_gather 8y ago
This was exactly my thought as well: parent might find that a different programming language/paradigm suits their natural thought processes better. Try out a Lisp, maybe, or even something real fun like Prolog. There's still details to be aware of, but they definitely have a different "flavor" that might be more palatable.

addicted 8y ago

I suffer from similar issues. Something that really works against me in the standard coding interviews. Some ways I try to mitigate some of those issues at work are: 1) Peer/senior code reviews. I try and get code reviews done by other folks. This helps with identifying something easy that I may be missing. Usually, once I already have a solution to a problem, I find it hard to revisit it without that solution overwhelming my approach, unless a bit of time has passed. Getting some fresh eyes to look at it helps. Also, explaining the solution to someone else often helps me identify issues with my solution during the process of explaining it to someone else itsel. 2) Practice and experience. I think for the most part intuition is simply the result of experience and practice. 3) Learning different programming paradigms. Something that has helped me more than anything else I think is learning programming languages that cover different paradigms. I’ve never coded anything useful in Haskell, but just the process of solving basic programming problems in Haskell, with its strong functional approach, helps me identify issues with the proceduaral/OOP code which I do write to solve useful problems. I think it allows me to approach each problem from multiple perspectives so even if I don’t have certain Haskell features available to me, it makes it easier to recognize that this may be an issue I need to address in my OOP code (for example, the Haskell compiler when pattern matching requires all possibilities to be addressed. Awareness of this fact means that anytime I’m writing conditionals checking the input I’m much more aware of the fact that I need to also handle the else condition, something that most non-functional programming languages don’t hsually require in their conditional constructs). 4) Related to #3m opting for better solutions wherever possible. I always try and opt for expressions over statements. I try to avoid state change as much as possible. I try and minimize side effects in functions, and try to constrain them in specific areas of code, etc. 5) Formal CS study. I don’t have a CS background, but studying formal CS in my free time has helped a lot. Getting better at data structures, algorithms, formal verification, etc, has helped develop my intuitions even if I don’t sctually use those data structures and formal verification methods in practice.

voidhorse 8y ago

I can speak to this issue as someone who comes from a formal background of philosophy and literature, but whose work involves a lot of programming (both reading and writing code) at this point. Foremost: practice. If you can read and write essays at a college level you've been practicing the craft for (likely) years. Most educated people in the US start engaging with letterforms as soon as kindergarten (!), and no later than 1st grade if not preschool. Contrarily, we don't start so early with the rules of logic nor programming constructs. Most folks don't start programming until much later, and even those who are precocious in this regard usually don't begin using "real" languages (in other words, not stuff like lego robotics or scratch) until they are ~13 or so (of course, there are plenty of exceptions). As with most skills, practice is invaluable. On a conceptual level, I found that making the jump from asking myself what does this code do to what does this code mean majorly beneficial. It may seem like a minuscule or pedantic semantic point, but it actually makes a world of difference. Just like essays, programs are expressing—they are saying something. If you shift from approaching programming from a goal oriented perspective to a communications perspective your code will probably improve immensely. I think this is the reason guys like Donald Knuth stress code readability and literate programming so heavily—at the end of the day, that's what's really important: communicating some idea—just like we do in plain old english. We simply have a broader audience (the latter part of which is very picky about what it understands). The notion of a proposition in logic doesn't do, it means. Programs are essentially a set of propositions which just so happen to have the side effect that they can make a device (a computer) do something when it interprets them. Just as linguistic commands ("go to the store") are "pure" and free of side effects in and of themselves—they only have effects under human interpretation. On a somewhat related note, I find stepping away from programming languages and starting with pen and paper is great. I think people tend to let programming languages get in the way of the real nature of what it is they're doing, which is solving problems in a structured manner, using mathematics and logic (algorithms and data structures). You don't need a programming language to do this, it's only a vehicle to express your solution. Just as you'd often start writing a formal paper by exploring your ideas in an outline or notes, or a couple of first drafts in which you hash things out, you can start "programming" by sketching ideas for solutions and better comprehending the problem at hand. This will ultimately help you write better code. I think a lot of self-taught devs, such as myself, miss this part early on as our entry point into the discipline is often through the languages and tends to kind of remain at the level of the languages we like unless we dig deeper into the underlying formalisms driving them. Too often people just go along with their first-pass understanding of a problem and begin reaching for the libraries, language constructs, etc. that they think they need. Someone with formal training, contrarily, has professors that can help them recognize the concepts behind the languages and connect up and distinguish the notion of a language as a mode of expression and programmatic problem solving as a practice irrespective of the selected language.