The code culture problem

"Brogrammer" is ill-defined. It's silly to blame something on an ill-defined concept.

http://gizmodo.com/5910824/theres-no-such-thing-as-a-brogram...

As a coder the best compliment I've ever gotten was from a consultant. It was basically something like, "Hey, you're the [my initials] that wrote a big chunk of [system]? I can really tell the parts you wrote from the rest, it's so much easier to follow and understand." I had written the original code for that project solo and then it was passed on to another team for maintenance. That, to me, is the best thing a fellow coder can say, that my code was easy for them to maintain.

Conversely, I've seen code written in Java where instead of using objects the original coders used hashmaps with key/value pairs for fields. Sometimes they used some public static strings or an enumeration for the keys but often times they're just randomly hard coded throughout the program with string literals for field keys.

In another system I've worked on the coders did not understand objects/collections at all. So rather than having an array of type Person you had the Persons object that looked like this:

Persons { String[] first_name; String[] last_name; String[] address; }

While it's true that good vs bad code is somewhat subjective... code like the examples I provided above is pretty horrible by the standards of all but the worst coders.

Well said. My most important development as a programmer has been my skill in reading other people's code. I've noticed that I think a lot less code is 'bad' nowadays. A lot of the time, it's not how I'd write it if it were me, but that's not the same as it being shit.

Why would you bet that?

We have a broad understanding of how to structure and write software. These ideas have been collected together in books. I refer to books like Code Complete, Debugging the Development Process, Clean Code, Refactoring, Programming Pearls, Beautiful Code, and so on. Then there are the language specific books. I don't believe you can craft well written C++ without reading Scott Meyers' books (or having absorbed the same knowledge from others), for example. Even the much maligned Design Patterns, which has been turned into the truly dreadful design by pattern, helps us to think about how to structure code.

I can't type it all in a post. But we are talking about modularity and extensibility. Decoupled code, so you can make changes here that don't break something over there, and so you can easily move code from one project to another. Well commented code - where 'well' means the author takes the use of the code into account - some deeply internal function named ComputeAverageSalary probably doesn't need much in the way of extra comments, anda top level api call to a framework being used by thousands needs a lot of documentation. Well structured code. The if statements make sense. They are not deeply nested. logic is not duplicated, or contradicted when it is nested, because that always leaves you scratching your head as to the purpose of the author(s), and clueless as to how to add code.

So, back to the question, why would you bet that? I've opened plenty of 15 year old code that is good to beautiful. This is not an arbitrary judgement of "oh, OO good/bad", nor an reactionary "it wasn't written by me, so it must be bad".

I do consider myself a pretty clean programmer, but I learned it by observing the code of others, reading a lot of books, and relentlessly applying a critical eye on everything I write and others write. All borne not on some arbitrary judgement, but from recognition of how quickly/slowly I can grok a piece of code, how easy it is to find and fix bugs, how easy to add features, and so on. In some code bases that is all fairly straightforward, and in others it is impossible - any fix or change has so many side effects that you need to add 50 if statements strewn about 50 files, in code already filled with if statements, and your if statement break about 15 undocumented assumptions about the behavior of the tightly coupled code.... that, my friends, is shit.

This also seems like something you could get fired for. You are not just disrespecting your teammate's judgement but also your boss's judgement in hiring your teammate. Therefore you are not a team player and maybe shouldn't be on the team.