Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signs that you're a bad programmer

sites.google.com

Post reply on HN
Print view View original

81–90 of 131 posts

Re: Signs that you're a bad programmer

#81

Post by torpor »

sfk wrote: post #80
torpor wrote: post #75

How to avoid (if you're a C programmer) writing utterly terrible code - always include these WARNINGS in your build step: WARNINGS := -Wall -W -Wunused-parameter -Wmissing-declarations WARNINGS += -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare WARNINGS += -Wconversion -Wshadow -Wcast-align -Wparentheses WARNINGS += -Wsequence-point -Wdeclaration-after-statement -Wundef WARNINGS += -Wpointer-arith -Wnested-ex…

Good advice, but compilers often issue warnings like "x may be used uninitialized" even when it cannot happen.

Erm, wut? Not really. If there is a warning, its there for a reason. Fix that.

Re: Signs that you're a bad programmer

#82

Post by axod »

scottdw2 wrote: post #71

I have to say, I really didn't like the document much. Not because of substance. Some of what he says is true. On style, though, I think the document is trash. Some of what I say is probably even a bit ad hominem. Most of the good programmers I know don't spend time worrying about bad programmers. They just write good code and cleanup bad code when they see it. If someone feels compelled to write up an essay about ba…

>> "They where hired under the same standards as you."

The problem is though the hiring process for programmers is often completely broken. Measuring good programmers is also broken in many companies, so bad programmers tend to just stay there instead of improving, or being fired.

I think being a good programmer isn't too hard if you have the talent, taste, time etc. Being recognized as a good programmer, and rewarded as such is harder.

Re: Signs that you're a bad programmer

#85

Post by sophacles »

gaius wrote: post #42
sophacles wrote: post #14

Earlier quoted context omitted.

This one time I had to work at a place where a postgresql install was not only the main datastore, it was also the main system message bus by abusing notifies. Further the enterprise message bus was a homebrew thing that was written to both pass messages and do RPC, oh and be the main way to monitor if a remote site was up or not. I think both of those count as well. For those who are curious: given these were linux…

See to me, those look like homebrew solutions, and Tibco/RV or MQSeries is the proper answer. It's easy in retrospect, but Postgres predates JMS etc by a loooong way - who's to say that wasn't the best solution at the time?

Good question! The postgres solution was unexcusable, it was always used side-by-side with dbus. The other was around before any affordable[1] enterprise message busses existed, however as that changed the buggy solutions was still touted as "amazing new tech that keeps us ahead ofthe competion. No we can't switch to something else".

[1] Affordable being defined as: this particular company could pay for it without going out of business.

Re: Signs that you're a bad programmer

#86

Post by bartw »

drusenko wrote: post #67
sjf wrote: post #61

Earlier quoted context omitted.

That's a bit harsh, that's a distribution problem, not a development problem. It's been long time since I've used free hosting, is there provider that doesn't limit bandwidth? (This is just out of curiosity.)

We don't :) (Weebly)

Not yet.

Re: Signs that you're a bad programmer

#87

Post by sophacles »

321abc wrote: post #36

The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…

I have done this too, particularly in small projects. One thing I try to do in these situations is imagine what functions would be useful should I extend the program later. Anther trick is to imagine a different pardigm, i.e. coding it up as a state machine.

What I gathered from the original article however, is a focus on those guys who will decompose long_function(params) into short_func1(params), the last line of which is return short_func2(params, 12 state params); .

Re: Signs that you're a bad programmer

#88

Post by tetha »

rjurney wrote: post #12
jcapote wrote: post #4

This is spot on: 5. Lisp is opaque to you

I can't learn LISP. I can get reasonable work done in imperative functional/OO languages like Perl, C, Java, etc. and took the time to learn Erlang to get a look at functional programming and I can drop the SQL bomb like nothing else (so I can do declarative too) but every time I've sat down to learn LISP because people say it will make me a better programmer, I've gotten distracted and haven't finished. I don't thin…

I think LISP, Haskell and 'Learning Lisp' or 'Learning Haskell' is nothing one should take too literal.

I think the point behind such statements is the point, that Lisp and especially Haskell today are very, very advanced languages with very, very advanced and abstract concepts (best example: Monads.). If you 'Learn Haskell', or 'Learn Lisp', the speaker will usually mean: Learn these abstract and advanced concepts. Learn to love homoiconic languages such as Lisp, Factor, and learn to love the mathematic backgrounds in haskell, with its Monads, Types, Monoids and whatsoever. If you have groked those concepts, you will usually make a serious step on the ladder of good programmers.

However, as 'Learning Lisp', or 'Learning Haskell' are just a way to say to learn these very advanced concepts, it can be very possible that one knows these concepts by heart already. So, if you know functional programming, the most interesting part about lisp reduces to macros, pretty much. (I know, I will be bashed, because there will be one or two interesting features I forgot, because I did not venture into the LISP-Land too much, because the madness of interpreters and such was too big for me, but the point still stands.)

Re: Signs that you're a bad programmer

#89

Post by kls »

extension wrote: post #69
321abc wrote: post #36

The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…

A precedural decomposition should at least partition your code along meaningful lines so that a reader can potentially find something faster or understand its functionality in simpler terms. If they have to jump all over the place to make any sense of your code, you're just obfuscating. I've seen plenty of bad code where a task is broken down arbitrarily, creating sets of procedures like foo, begin_foo, execute_foo,…

it is not a problem with OOP so much as it is with the abuse of OOP, which is easy to do. Bad developers put the work flow procedures in objects and treat it as if it can be used as traditional OOP. but the truth is that work flow is usually task specific and not reusable. It lends itself better to procedural programming. Good OOP programmers know to stuff this stuff in thread safe static subroutines(methods) and provide a service layer for all work flow. it should not be embedded in objects (i know technically the static methods are in an object). Unfortunately this has also caused another bad OO problem with anemic objects. If you look at MVC implementations like struts it has caused a new bad habit in which objects are used for nothing more than structures and all of the logic is implemented in the work flow. Reusable business logic should be implemented as methods on the object in which they relate to. User specific work flow should be abstracted away from the objects and the UI should be loosely coupled to the work flow through a service facade. Alternatively if you have a group of good OO programs you can implement the work flow elements in a reusable event based system where reusable paths can be developed and listeners can chain in for very specific non-reusable tasks, but this is very hard for a junior to follow so many good developers opt for the first pattern because it allows them to train new developers on the system, without having to teach a programmer event based techniques. I don't know why it is so hard for people to grasp OO, but it does seem like it is much easier to create a hideous unwieldy beast with it, than procedural, in the hand of the wrong developer. Conversely, some of the most elegant systems that I have seen where done with OO languages and properer delineation between the data systems the business model and logic, the work flow and the interface.

Anyway, long story short when I see a huge stack chain, general they are either do anemic objects and just hacking up the big controller procedure into a bunch of little functions or they are doing OO work flow, either of which is not an appetizing prospect to support or fix. Evey once and a while you will get someone that is doing factory patterns everywhere which can create a lot of deep dives down the stack to figure out that the 17 methods deep stack finally results in one method creating a object.

P.S. Private subroutines do not have to be reusable public ones should be. The author did not specify. so I hope and assume he was talking about public subroutines.

Re: Signs that you're a bad programmer

#90

Post by [deleted] »

tetha wrote: post #88
rjurney wrote: post #12

Earlier quoted context omitted.

I can't learn LISP. I can get reasonable work done in imperative functional/OO languages like Perl, C, Java, etc. and took the time to learn Erlang to get a look at functional programming and I can drop the SQL bomb like nothing else (so I can do declarative too) but every time I've sat down to learn LISP because people say it will make me a better programmer, I've gotten distracted and haven't finished. I don't thin…

I think LISP, Haskell and 'Learning Lisp' or 'Learning Haskell' is nothing one should take too literal. I think the point behind such statements is the point, that Lisp and especially Haskell today are very, very advanced languages with very, very advanced and abstract concepts (best example: Monads.). If you 'Learn Haskell', or 'Learn Lisp', the speaker will usually mean: Learn these abstract and advanced concepts.…

[deleted]
Post reply on HN