Be nice to programmers • Hacker News Board

Re: Be nice to programmers

#21

Post by munin » Tue, Oct 09, 2012, 4:23 PM UTC

how do you create good and worthwhile things if you do not try and make them better? how will you make them better without finding the elements that can be improved and improving them? maybe this is part of the engineering mindset, the ability to approach the world with "how can I make this better" and not be depressed and overwhelmed.

I used to get super frustrated and depressed when people edited my writing/prose. each comment was some way in which I sucked. then I compared, side by side, my early drafts with finished works. now I'm not frustrated or depressed when people find problems with my writing! or my code.

Re: Be nice to programmers

#22

Post by Vwoods111 » Tue, Oct 09, 2012, 4:24 PM UTC

I think that people need to realize that a developer is someone that simply builds the solution to a problem no matter what that problem may be (ease of use, a new business etc.) If you use that train of thought it only makes to focus on all of the things that do not work to successfully achieve the goal of finding the thing that does. So regardless of how good their code is the developer has to have the mindset of first fixing all the bad to deliver a working solution.

Re: Be nice to programmers

#23

Post by wvenable » Tue, Oct 09, 2012, 4:26 PM UTC

daenz wrote: post #6

It sounds like a plateau, where he's not getting noticeably better from the mistakes he's making (so that he's not making them as much with each chunk of code he writes). Maybe this happens when you're close to your full potential?

Programming always gets more difficult. I'm a much better developer than I was 10 years ago and I don't make the same design or development mistakes. But instead of writing perfect code, I'm working on larger and more difficult problems. In fact I'm now responsible for so many more platforms, systems, and programs that I probably spend more time dealing with problems than ever before.

Re: Be nice to programmers

#24

Post by dustingetz » Tue, Oct 09, 2012, 4:27 PM UTC

MatthewPhillips wrote: post #19

dustingetz wrote: post #9

TLDR: write better code functional programmers get to express their ideas as code imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas just look at the research[1] coming out of the Clojure functional programming community - especially Datomic. once you learn how to get your defect rate under control, you have time to explore crazy awesome new idea…

Most bugs have nothing to do with the code being imperative.

http://www.infoq.com/presentations/Simple-Made-Easy (this is so fundamental to this topic that it is required watching to even have an opinion on this subject)

http://clojure.org/rationale

http://www.dustingetz.com/2011/05/05/how-to-become-an-expert...

http://www.dustingetz.com/2012/10/07/java-sucks-because-idio...

Re: Be nice to programmers

#25

Post by dbaupp » Tue, Oct 09, 2012, 4:27 PM UTC

dustingetz wrote: post #9

TLDR: write better code functional programmers get to express their ideas as code imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas just look at the research[1] coming out of the Clojure functional programming community - especially Datomic. once you learn how to get your defect rate under control, you have time to explore crazy awesome new idea…

Languages like Haskell show this tendency too, e.g. Oleg's work[1] (which includes research with lisps) although he also does awesome stuff with imperative languages too.

[1]: http://okmij.org/ftp/

Re: Be nice to programmers

#26

Post by kranner » Tue, Oct 09, 2012, 4:30 PM UTC

Taking the time to do postmortems can help.

My partner and I just had our first iOS game approved. We had to ship without a bunch of features we had planned for (e.g. non-English localizations) simply because we ran out of time. During the final stages of the project, we thought we'd like to do something like a web-comic, to share the human story behind the development of the game. Now that the game is approved and we're reviewing our notes and drawing the comic (it can be loaded dynamically into the game as a slideshow, and it will also go into our facebook page/company blog at http://noisytyping.com), our view has shifted from 'we could have done better' to being very pleased about the whole journey: how we started out, what challenges we faced (automating level-generation was one) and how we managed to stick to our plan and ship it. Without the postmortem, we'd probably never be motivated to make a game again.

Re: Be nice to programmers

#27

Post by microtonal » Tue, Oct 09, 2012, 4:32 PM UTC

dustingetz wrote: post #9

TLDR: write better code functional programmers get to express their ideas as code imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas just look at the research[1] coming out of the Clojure functional programming community - especially Datomic. once you learn how to get your defect rate under control, you have time to explore crazy awesome new idea…

functional programmers get to express their ideas as code imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas

Stop drinking the cool-aid. Functional programming solves a lot of typing errors (if the given language has stronger typing than an imperative language) and makes composition easier in some cases (if the language is lazy).

But: an algorithmic error is still an algorithmic error, an incorrectly designed data structure is still an incorrectly designed data structure. No matter what language you use.

In addition to that, you get back a different set of problems: e.g. you have to reason about when something gets evaluated in a lazy regime in order for your program's heap not to blow up, and the translation to machine code is often not nearly as simple as an imperative language, which makes it harder to optimize functional programs.

(Ps. I love functional programming.)

Re: Be nice to programmers

#28

Post by MatthewPhillips » Tue, Oct 09, 2012, 4:34 PM UTC

dustingetz wrote: post #24

MatthewPhillips wrote: post #19

Earlier quoted context omitted.

Most bugs have nothing to do with the code being imperative.

http://www.infoq.com/presentations/Simple-Made-Easy (this is so fundamental to this topic that it is required watching to even have an opinion on this subject) http://clojure.org/rationale http://www.dustingetz.com/2011/05/05/how-to-become-an-expert... http://www.dustingetz.com/2012/10/07/java-sucks-because-idio...

You don't have to convince me of OOP's faults; Clojure is my favorite language. But I write code for a living, mostly in OOP because that's where the jobs are, and I do not write very many bugs caused by OOP's poor design. I write bugs when the business is ill-defined, or when I misunderstand how a library's APIs are supposed to work, or when I'm careless and don't consider "what do I do if this function returns false"; all stuff that will come up in FP as likely as it will in OOP.

Re: Be nice to programmers

#29

Post by hkarthik » Tue, Oct 09, 2012, 4:34 PM UTC

I can identify with some of what the author has saying, as I've struggled with a pessimistic attitude throughout most of my adolescent and adult life. However much of it was formed long before I learned to code. I've recently been working to be more optimistic as I think it can be learned.

However, I suspect pessimists tend to make good programmers rather than programming causing someone to become more pessimistic.

If you're interested in understanding some of the psychology between Optimism and Pessimism, I recommend reading Learned Optimism by Martin Selligman. http://amzn.com/1400078393

Re: Be nice to programmers

#30

Post by peeters » Tue, Oct 09, 2012, 4:38 PM UTC

There is nothing intrinsically negative about anything said here, just neutral things viewed in an extremely negative lens. Here's the exact same set of steps making up the "normal workflow", but framed as a positive feedback loop:

  1. write some code
  2. run the code  
  3. get further than you did before (perhaps with a new error message)  
  4. decide what's next and go back to step 1

I don't think negativity is intrinsic to the profession. I get to build things every day. I get to fix problems. That's an incredibly satisfying and positive thing.