The code culture problem(fraustollc.com) |
The code culture problem(fraustollc.com) |
The above said, sometimes code is really shit!
However, sometimes code is just shit.
The first step to fixing a problem is admitting the problem exists. Attempting to cover it up it with words like, "well I'm sure there is a good reason for that" or "Hrm that could be better but I know we had crazy deadlines." Are just excuses and don't really help.
If looks like shit and smells like shit... well it's probably shit.
We are all big kids here, no need to sugar coat things.
The problem, if any, isn't the criticism itself, but the lack of explanation. If you can argue for why a piece of code is shit in a way that will help other developers, please do!
On the one side, it's a bad thing. On the other, it's stereotypical dudely behavior, and should be made fun of. "This is shit!" is, from my point of view, a way to observe that code 'feels' off, and an exclamation of frustration in that the reader can't understand it right away - and apparently doesn't have or can't take the time needed to dig in and understand it deeper.
I often go for gut feelings in judging code (this is shit!) too, so I can understand. I can understand the frustration too when one can't spend the time to understand and fix it - besides, someone else wrote it, someone else should fix it.
tl;dr, it's complicated. If someone exclaims "this is shit", go and investigate. Sit / pair with the person, walk through the code - or even better, if possible, find the person that wrote it - and either make it unshit, or make the person making the observation understand why it's not shit.
Also, whatever your favorite "technology" is today is probably a bad joke to the next guy.
http://en.wikipedia.org/wiki/Code_smell
And magically the number of "this is shit" comments decrease dramatically. The problem is that people don't like seeing easy to spot problems, but instead of giving people a guide, they complain.
Shit code, mine or others, highly motivates me. To refactor/fix it. To the point I have a really hard time making targeted, single purpose commits.
Because I have pride in my work, concern for the dev who has to maintain this shit after me, and understand costs of technical debt.
I wonder where the whole "Worse is Better" paradigm fits into the universe with good code, acceptable code, and "shit code".
If no one other than the 6 people you're working with have ever read the code and nobody wants to add code to it, you need to really spend some time reading the code before you make a judgement call. At that point, it's better to make the code not shit than simply call it shit.
In software, if you can articulate why it's bad, you can fix it. If you can't articulate why it's bad, keep it to yourself.
https://lkml.org/lkml/2013/7/13/132
We need more developers like Torvalds - not because he's nice, but because he's terrifyingly experienced and completely honest in his feedback. I couldn't think of a better mentor.
If shit code is performant, correctly solves the intended problem, is well-tested and bug-free, is it really shit code?
not sure why i hold onto this 20 years out of date mentality..
I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code.
But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm they were developing in and the tools they were using to do it, and actually gave crap".
The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear.
I completely agree with the point the author is trying to make about the attitude problem, especially amongst coworkers, but let's not gloss over the fact that halfway decent code written by competent developers is still very, very rare.
Most code out there is shit code. Denying it is not going to help either.
I'm sorry, I respect your experience but this post is completely uninformative. It's much more specific on how awesome you are than on how to distinguish between "shit code written by shit coders" and "less than optimal code written by good coders"; not to mention dealing with and improving either.
It's possible to spend a long time in an industry and accumulate much unfounded prejudice along with solid knowledge. As long as the appreciation of "shit code" and "shit coders" remains subjective, it's virtually certain you'll also be considered one someday, when the prevailing paradigms and fashions change again.
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.
It's stark in the arts, but it applies to almost every human endeavor. As an example in the arts, I dance, and I'm good at it according to almost everyone who sees me dance. But I see myself as a terrible dancer. If I make a video of me dancing, others see every part that's well executed. I'm accustomed to them, and I tend to ignore those parts in favor of every part that's sloppy, every part that just doesn't look right.
And it's no different for code. You know what one of the marks for good code is? If the guy writing it is tearing it apart in the comments. Where do you see /* This is a dirty hack I'm ashamed of */? Usually right next to stuff that's a stroke of genius, or at the very least really good code.
It's strange that the more you know about something, the less comfortable you get with your knowledge, but it seems almost universal that "Ignorance is bliss", or rather the corollary "The more you know, the less you think you know".
Unfortunately that pretty much means everyone is shit relative to someone else.
So its important to remember, you are shit too.
However, I find that it's more helpful to have a positive attitude when reading code I didn't write. "Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with".
I'm not denying that I found seriously bad code running in production. And I'm not denying that it's more common that I would've believed. But the moment I start treating every piece of foreign code as shit, I'll miss out on interesting insightful techniques.
The point of this article is a reminder that it's easy to get sucked in the "this is shit" culture.
You're 3 years in. In another 3-5 years (maybe more), this 'positive attitude' will (and should) go away. You'll have a much better understanding of the 'weird' ways, and will be able to tell 'quick hacks' from 'crap code' as the OP was referring to.
You will have learned most of what you need to know by investigating the 'weird way', and you'll see the patterns, and you'll be at this for 15 years, and you'll be seeing the majority of stuff coming out being crap code by younger developers. It's the way of the world.
The article is not about the existence of shit code, the amout of shit code produced per year or how much shit code the average developer will see in his career.
It is about teamwork, and what kind of culture poisons the atmosphere in a company.
Not about shit code, which by the way everyone here has produced at some point or to be more realistic about it (since usually developers look at their old code and think it is bad) - is still producing on a daily basis.
Once I finally understood what it was doing enough to refactor it I managed to delete most of the file and replace it with a "latest_id" counter which incremented on each call, with the success handler skipping if its ID wasn't the latest. Simple.
I approached the developer responsible for the original, to show him what I'd done and explain how Javascript's scope let each call have its own ID. His response was that I'm using obscure language hacks which nobody is going to understand when they have to maintain it, that I should stop trying to force everything into a few lines and that he doesn't need to learn about Javascript's scope because he can already program so learning anything else is a waste of time that could be spent coding.
I got told a similar thing during a code review as well, since I'd used map on an array. Needless to say, I didn't stay there long.
Now that is a cultural problem, which can only be solved by pointing out shit code (although in a more polite way). Some people are so stuck in their ways that they don't care about improvement because they see their stuff as 'good enough'. In those cases, they need to be shown that no, it's not good enough, because XYZ.
I wasn't trying to gain points on anyone; I was just frustrated at the utter lack of care about the codebase we all had to work on. Whenever I spotted anything particularly WTF I'd send out a "Code of the day" email. My favourite is still this one:
<td>
blah blah blah
</td style="....." id="foo" class="bar baz">He took the one thing he could make an easy, pedantic point about and posted it. It's easier to do that and get free karma that actually be mindful. It's low hanging fruit. Just like I could find errors in his comment that would serve no purpose.
At issue is, while his point might be technically correct, it serves nothing other than to encourage "Me too" replies. This happens frequently on HN. I encourage you to down vote such posts.
It's like the friend who complains about everything all the time: constantly complaining about traffic, about the weather, about how the city is losing its charm, about his job, about his classes, about his parents, about his car, about his apartment, about politics, about how stupid people are, etc. etc., with nothing positive to say. Maybe it's all correct from some perspective, but it's not a very useful perspective and it's definitely an annoying one to be around.
"All software sucks, be it open-source [or] proprietary. The only question is what can be done with particular instance of suckage, and that's where having the source matters." --viro
What do you think makes your code good?
I bet the next guy that comes around in 15 years and reads your legacy code (Grats on having code actually runs for 15 years!) will think it's the worst piece of shit ever created and are sure to think you are one of the worst developers in the world.
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.
Answering for myself: (1) it's short. Often significantly shorter than my colleagues'. (2) it has few bugs, if our bug tracker is to be believed (I reckon I'm not very confident about that one).
On the other hand, I tend to be slower, especially when I have to write against less than optimal APIs.
Simply understanding that something will be a maintenance nightmare should inform a developer enough so that they, at the very least, leave useful info/docs about what corners were cut and why. Until you've had to deal with mountains of various legacy projects completely undocumented, you won't even know this is something you should be doing.
The other 50% is implementation.
To err is human; to really screw up takes a committee.
semantic point. if you're saying 'most code' is shit, aren't you saying average code is shit?
Kind of like saying a 6 min mile is shit because it's not a 4 min mile.
Also, comments-used-as-source-control. If I see one more gigantic block of code commented out with a set of initials and a date "this was removed by/on". Use the source control to do that, dammit.
Well, sometimes I do see code that's really very bad and I can't imagine how someone was ever able to type something like that, but that's rare. Usually it's competent people with the best of intentions but as lack of ability to predict the future.
Is code that was written on time and on budget - but has a few hacks in it shit?
Is code that is beautiful and easily maintainable, but was £1m and six months over budget not shit?
So you do it "right" then, I assume. What do you think the next guy is going to say about your code? Do you really think they're going to praise the excellent code quality? Or will they declare to all around that it all needs to be rewritten because it doesn't conform to the newest flavor of the month?
I absolutely and unequivocally agree with the author: People declare everything around them as shit to prop themselves up, and the explain their own inadequacies in advance. There is shit code, granted, but by some measure of shit all code is shit. A viewer can destroy code as over or under engineered, over or under built, over or under abstracted, over or under object-oriented, over or under functional, and on forever, and anyone who thinks there is an actual right way in any reasonably complex system is demonstrating profound naivety.
The one thing that I will disagree with in the submission is the notion that this is a new or increasing pattern. It isn't, and has been the norm for decades. This is what developers do, especially those who are weak at reading code: Declare it shit in advance and just write your own.
I'm not talking about a mismatch between approach (over- or under- whatever) and goal. I'm not talking about quick hacks that were never refactored (because of course, there never is time). I'm not talking about code that has gone through many cycles of unpredicted change and has acquired many layers of cruft. I'm not talking about code made by inexperienced developers who still have a lot to learn.
I've seen all that. I've written all that. I've left code behind I would be embarrassed to show in public. I'm shocked some of it is still in use, and I'm sure people who have to maintain it will curse my name. That is part of the job.
What I'm talking about is pure, unadulterated shit code. No structure, no logic, no consistency and barely functioning only under very limited conditions. Utterly incomprehensible unless you immerse yourself deep into the mind of the author like an FBI profiler and a serial killer.
No, there is no one "right" way of writing code, but boy there are an awful lot of "wrong" ways.
There were 3 client-side javascript files. They were named something like this:
foo.js foo2.js foo-z.js
Each file was about 4,000 lines long. All 3 were nearly line-for-line identical, save for about 500 lines of differences each, strewn wantonly about. For some of the URLs the app would use foo.js, for some other URLs it would use foo2.js, and for yet more of the URLs it would use foo-z.js.
There were 4 files on the server like this which did the same thing - copied line for line and then changed in various places.
After refactoring these files together and eliminating the duplicate code, I ended up deleting something like 8,000 lines of code. I quit soon after - by then I was already looking for another job.
That code was shit. There is no question about it.
You lucky swine… Much (possibly most) code I have had to deal with was that ugly.
An unfortunate side effect is that this perceived badness of the code is then often used as an excuse to not really try and understand it at all ("let's rewrite!" or "we don't touch that anymore").
Sure there are the obvious mistakes like non-idiomatic code style. But that's easy to spot. But for anything that is related to the problem domain and not the language itself you need to dig deeper. Because there might be a very good reason why something is done the way it is done. And later you might think: Hey, that's actually a pretty good solution.
Wading through piles of code by dozens of different developers made me humble and nowadays I think twice before calling something bad.
What was seen here is a particularly insidious, caustic and ultimately, demoralizing and self-defeating attitude from your colleague (and something I've seen routinely on HN). I don't particularly think he was in any way truly convinced that it was deserving of it, however it must be thrashed in accordance with a self selected pecking order in order to assert his dominance.
This "politeness is rubbish" attitude which also applies to common niceties in communication will one day be the death of us all.[1]
There is truly awful code out there and it doesn't deserve commentary or any other sort of attention. Just a yanking and replacement with good code.
[1] Politeness devoid of sincerity is not politeness. It is in fact the worst of all forms of rudeness.
[1] http://staefcraeft.blogspot.com/2013/07/linus-torvalds-there...
http://gizmodo.com/5910824/theres-no-such-thing-as-a-brogram...
Those are both fuck ups. So, I respectfully disagree that "stop fucking up" leads to those ever and suggest you don't understand what fucking up entails.
Straight up honesty is the best medicine when it comes to software. If you have a problem with this kind of honesty, find something else to do.
Or they're just adhering to the culture of calling all imperfect code shit because that's what they see others doing.
>> But it is important to be intellectually honest, and not be egotistical about one's own code, which could be shit just like anyone else's.
Well said.
On the other hand, sometimes code really is just shit. Being positive and saying "this is a good start, let's go through it and see if we can improve upon it" might be a massive waste of time if it's really shit. Sometimes holding people to high standards is necessary so the whole team doesn't get held back.
If the code is bad, then improve or replace it, and do your best to help that developer improve his own skills, so this wont happen again.
If code output is constantly bad, then fire the developer, but there's also no reason to be condescending here.
I just can't see that treating a developer (or anyone else) like shit is going to have any positive outcome considering the current market for developers, where demand is much higher than supply.
There is a reason that you are reading it: you are maintaining it, adding a feature or trying to fix a bug. If it is not easy to read then it makes this harder and that makes code bad and increases the chances of the editor making a mistake and breaking the system. (Or just making your day bad).
Maybe because there are only so many straight answers and we get tired of repeating them so often...
Class A: It's too difficult for the next programmer to understand this
- poor (or horrible) variable naming
- poor (or horrible) function naming
- repeated repeated repeated repeated code
- comments don't match code
- comments needed but not there
- comments needed by unintelligible
- unbalanced structure
- poor (or horrible) choices for iterations
- poor (or horrible) choices for conditionals
- poor (or horrible) choices for data design/storage
- poorly maintained by Programmers #2 thru x, who didn't understand it
- etc., etc., etc.
Class C: It's broken. Insufficiently tested & broken in production.
They also don't know that they don't know this, because they've seen code that's comparatively easy to read -- why, they've written it themselves! Their implementation of only the minimal requirements of the domain is much clearer than someone else's complete solution with all its required business-warts. As such, obviously, throwing out the previous complete solution, and filling in the gap with their own minimal reimplementation, is an improvement. (They don't notice that after fixing the ensuing regression bugs, their version now bears a much stronger resemblance to the previous one....)
Eventually, you read enough code that you get used to that particular "smell," and you realize that it's not really pungent in the way the other smells are. The "complex problem-domain, completely expressed" smell becomes the grease on the equipment[1] -- the sign of a well-patched and long-running system.
---
Usually I find talking like this helps people admit when code is just bad or they try to clarify it. I've found it makes asking whether it's ok to do complete rewrites a lot simpler.
It's one thing to be able to recognize shitty code in hindsight or in another developer's work. It's quite another to be able to catch yourself before you write shitty code and do better.
This hits at one of my least favorite memes around here. The whole all the code I wrote six month ago is shit, and I will think that about the code I am writing now in six months. Yep, if you haven't developed the skills to determine what is good or bad about the code you wrote six months ago then A) It probably was middling code B) You aren't getting any better because you are unwilling to honestly critique your own work to look for areas that need improvement.
Maybe instead of saying that code is "shitty", we should retrain ourselves to say that "this code has no tests." It's more productive and points us to a direction out of the situation and prevents us from getting in the situation to begin with.
I suppose some might argue that shit code is not necessarily legacy code or vice-versa. Perhaps, but in either case the first step in improving it is to get it under test.
Because that's what "legacy" code is, if it wasn't doing something vitally important, it could just be deleted. It's not shit, it's the family heirlooms!
Hindsight is 20/20. Imagine auto makers comparing product today with those from 50 years ago? That's about how far we've progressed in 10-15 years in this industry. Were those guys whose contemporaries were able to send people to the moon on CNC-less machine tools and computers with 4K RAM somehow doing "shit engineering?"
Imagine if what someone sees as "shit code" ultimately made yesterday's coder $1000/line because it got done while there was an opportunity to sell it. Is it still "shit code?" You're not being asked to be a music critic here. Most code is written as part of a business.
That said, code reviews are a great way to learn from and align with your team!
I call bull. Java has plenty of issues, but plenty of plus points too, particularly for large-scale development on teams that experience employee turnover.
- Reasonably fast, considering the ease of development.
- Genuinely fantastic tooling.
- Generally discourages 'fancy' programming techniques. Obviously doesn't stop shit code getting produced, but at least tends to be relatively easy for maintenance programmers who weren't heavily involved in original development to understand.
I have to use Java for some of my work, and with the correct tooling it's really not that bad. Sometimes it's fantastic - when you're maintaining someone else's code, the ability to trivially (and exhaustively) find out what code calls this code, safely refactor and so on is invaluable. Of languages in its general class, C# is significantly superior, but tied to MS if you want a full-speed VM.
I'm not saying that you're likely to produce the most beautiful code of your life in Java, but compared to many other languages (+ toolchains) I find working on other people's code is rather easy.
For many developers, imperfect code, which is often more likely to be result of circumstances beyond the control of the person who wrote it than downright incompetence, is the gift that keeps on giving. If business and functional requirements were always well-defined and never evolved, clients/business stakeholders completely sane, deadlines realistic, resources plentiful and "scope creep" a rare phenomenon, a lot of software developers would be unemployed, and employed ones would be more frequently undervalued.
Sometimes, it is not really in the code or in the design. Some people are just downright evil.
In my experience, most of the time someone says "this is shit", it actually is, and it's indicative of serious failures in the hiring/training/code-review/management process.
The only ways that companies improve at those processes are by pointing out the shit, calling it by its name, and figuring out the best ways to keep it from happening again.
Having a "this is shit" culture can be GOOD -- it can hold people accountable and promote a culture of excellence.
> In the end it is a culture that values negativity rather than focus on solutions.
That doesn't follow. Call it shit, and then fix it.
> Start by understanding the code, and then find ways to improve upon it.
That means that, instead of fixing the underlying problem and making people accountable for their work, you take on the burden of cleaning after other people's shit? I don't think so.
The author is correct when they say:
> Don't blurt out negative assessments of others code for no reason, and with no understanding. ...Start by understanding the code
But that goes without saying. Don't be too quick to judge when you don't have the facts. But once you're sure the code is shit, it's ultimately counterproductive to hide that. Most employees will only start writing better code once they're expected to, and strongly held accountable -- like most people's performance in any job.
PS: To be clear, I'm not talking about disagreements over coding styles, etc. I'm talking about code with obtuse function names and no comments. I'm talking about CSS that is hack upon hack upon hack filled with negative margins and !important's. I'm talking about JavaScript that pollutes the global namespace by programmers who refuse to use "var". Or CSS declarations like "div div span div span tr td span {color:red;}". And there's a tremendous amount of this stuff out there. Stuff that there's never an excuse for.
Then begin to recognize potentially shit earlier in the process and while you do enough many rounds of that, confirming your expectations, you can just look at the code and say "this is shit" and be quite confident that you're right.
That's not to say that there wouldn't be a similar process working towards recognizing "When to rewrite this shit?" There is and the answer it gives is "Rarely".
A seasoned programmer will balance between "this is shit" and "not rewriting this shit". And there's nothing wrong with shit, because the shit is shipping and mostly works unlike the ultimate refactoring that nobody has time to write.
So it's the programmer's job to fix shit, and occasionally write new stuff that shall be deemed shit by a later fellow colleague.
Instead of pointing at the vague shitty attitudes towards shit, the author should probably just roll up his sleeves and start fixing the shit.
As I was trying to explain some of my, well non conventional ideas, another coworker pokes his head over the cube, and calls the design crap. This of course is nothing new, its almost a game for this particular engineer. In the end, I walked away trying to avoid the conversation. It felt emotional though, and frankly hurt my confidence (while probably inflating his own)
It kind of made me think of the phrase "no one ever got fired for choosing IBM" I could have chosen the obvious design, and gone forward. No one would have debated it. However I've done that in the past, and I've seen the terrible problems that come from it. My new design is an attempt to avoid those problems. The attitude really pisses me off though, and I find it extremely counter productive.
On the other hand, I do also recognise that some people just like to mess with others. In such circumstances, if there are no other political concerns, I would simply ask the person the come up with an alternative solution, then argue the alternative on its merits vs. what you have designed. Given your 70 pages of documentation, a simple pros vs cons list that takes into account goals of the project for various timeframes and scales should result in a clear winner. Or should both designs be of similar value, then there is little point in changing your documentation anyway.
In other words, we think out own code is "shit" so instead of dealing with that, psychologically, we just attack others.
I'm not opposed to calling out shit, even in my own work, but you ought to be able to explain the smell, even if it's something silly like curly brace location. (Ideally it's shit for a better reason... there usually is.) Besides if a rant doesn't immediately follow the declaration, you can't really claim to care all that much. If you're working on the Linux kernel and get flamed by Linus consider yourself lucky! It's because he cares. (And thinks there's still hope for you to do better.) I don't mind the rantless half-hearted calls of bullshit either; rather than leading to everyone feeling bad and trying to feel less bad by trying to make other people feel bad, I think it would sooner lead to more cynicism with insults and less taking offense and feeling bad.
asking people to be nicer in a technical environment would require similar levels of education and understanding of the tools involved. you seem to be a person that makes other people get stomack aches from bad code, so maybe you should reconsider your abilities.
if you write overall good code it's inherently easier to find a bug in it than if you just stitch shit together. if you solve your problems with stackoverflow and/or huge books like "how to... in 21 days" you should maybe reconsider your career choices.
in code the attention to detail is always more important than the overall intention, so why not leave it at that?
$query = "SELECT " + $_POST["foo"] + "...";
db_run_whatever($query);
It doesn't change what it is, or what it implies.
As a junior coder earlier in my career I found exactly the situation described. A co-worker was always griping loudly about how bad the code and architectural decisions of certain people supposedly were - all except his own, of course.
At first I was too diffident to form an opinion and considered whether he might be right. When I gained more experience, and finally got a look at what he was ranting about, it seemed to me that this guy's targets were not so bad and that his own output was hardly more impressive.
Eventually I saw other examples of this pattern and realized something: those who bluster in this way tend to be middle-range developers who are trying to cover up their own insecurities - while those who are really superior tend to be quieter, more businesslike and basically getting things done, and well, while those described above are going on in their "BS" sessions.
I don't claim to qualify for the latter group to the degree I would like, but when I hear the denigration, I ask what are the specific problems and what do we propose to do about them. And I try to promote a positive atmosphere, and really learn the code rather than just looking for where to put more duct tape.
yeah, if you're going to talk bad about anyone's code, start with your own. not even the things you wrote a few months ago, but like even today, writing xml schemas for a rest api, the whole time i'm thinking about all the ways the decisions i'm making are going to come back and bite me in the ass. not because i'm inexperienced but because i've written and worked with schemas and specs for interprocess communication before and know that any changes to the schema will require edits to multiple codebases and the time and effort to make some of those changes can be frightening.
i guess this is what fred brooks calls "the second system effect." it'll probably turn out that there's some other more terrible problem with the current system that i'm not even seeing because i'm overly concerned about the communication protocol on top and not the databases underneath or concurrency off to the side somewhere.
how many systems of some particular type does one have to build before not writing shit on the first pass? because, like, yes, the code freely available to anyone with a quick `apt-get source` is often of much higher quality than some things hidden in multinational corporations' private repos. so everyone can have some idea of what good code looks like now, but i am personally finding creating much more difficult than verifying and fear that it's going to take a lot of time to narrow that gap.
is it really necessary to work on like 8 processors before doing what someone like ivan godard does? maybe just 4 or 5 projects (which translates into about a decade, mind you) is enough before the "i'm fucking shit up" jitters pass for any particular type of system?
Making the code easy to read is simply a technical matter, an intrinsic quality of the code. However, your code cannot be easier to understand than the business it models.
To convince yourself, have a look at some (good) framework like a HTTP Server, ORM, or browser, ... Their code is generally miles away from what you expect and hard to read if you do not dedicate days or weeks to them. But it is not due to bad code but due to the fact that you are aware of only a tiny fraction of the problem they solve.
EDIT: (I realise I didn't make a point) My point is that it is not a hard rule. If you are experimented with the business, familiar (a bit) with the code and it is still hard to read that is the sign of trouble.
But in my experience those comments are usually found above cases where it's possible to make a fix in one line rather than one hundred. (sleeping a thread for 0ms rather than re-architecting a gigantic callback structure).
All I am saying (and I think the author tries to make that point) is that it is questionable that you are going to create such an environment by pointing fingers and treating devs bad.
My very limited experience (I am the mobile lead in a company) has taught me, having done all of that myself in the beginning, that I wont achieve anything this way.
What I saw is that people got defensive by default, protective about their work (so no one can attack them for errors they made), the company started bleeding talent (what person is going to like working in such an environment?) and so called "code monkeys" never improved, because they didn't believe that they could achieve anything meaningful by themselves.
For some companies this might work in a way that I can't understand, but I changed, because frankly I didn't like to work in such an environment myself, and it did have to some degree positive effects.
People share more information, there's less pressure generally and there is more trust in general that everyone is doing their best, and if unable to complete some task, will ask for help.
By the way, here's a Google I/O talk from 2010 about engineering leadership that covers the problems mentioned in the article - I cannot recommend it enough: http://www.youtube.com/watch?v=skD1fjxSRog
I've always found clean code to be faster to develop. I find that developers that produce lower quality code tend to spend their days debugging, fighting their code, reading and trying to figure out what they wrote 5 months ago, and so on. They are just not very productive. There are the outliers - people that have instant recall of all their code and elaborate mental models of really poorly structured code - but by and large I find that people that generate low quality code are quite slow performers.
I've worked in very good code bases, and very bad ones. In the good ones you can easily figure out what is going on, quickly make changes, confident that you aren't breaking 5 things because things are decoupled. You can produce new code quickly because you aren't fiddling with code nested 6 if statements deep, which is just about impossible to model correctly in your head. You aren't in endless compile/run/debug (or REPL/run/debug) cycles because your first try is usually just about right, because you can understand the surrounding code. I recently requested a simple feature, and was told it would take a week. I was dubious. Then I looked at the code, and decided that they were being conservative, if anything... for something I thought would reasonably take a few hours.
This is just an impassioned plea, not to Jach, but to the profession, to cast a critical eye on code. You can produce high quality code quickly. Not "nuclear reactor" quality, but pretty close. Bad code always costs you. Always. Don't write that way, don't allow it in your code base, or in your teammates.
Honestly, I believe that this is one of the best habits I've developed at my current workplace. We use Code Collaborator (a code review tool) for about 90% of all commits; I like using to get at least one pair of eyes on my code, but even further, I only even send out a review after I've gone through my own diff with a fine-toothed comb.
A better slogan might be "always make new mistakes".
FWIW: when I was fresh out of school my logic was sometimes pretty twisted, to put it kindly. Lots of deeply nested if statements, global variables used to maintain state (in the state machine sense) that sort of thing. That is unworkable, I recognized it, and I learned from my peers, from books, from good code, from myself (reality is a wonderful instructor. Work til midnight fighting a bad piece of code you wrote, well, you should learn something from that). That's not ego, that is learning your discipline.
This is all testable in the marketplace - not in products sold, but the marketplace inside your development lab. Are you the programmer with endless bugs, or the one that generates nearly bug free code. Are you a 10x programmer, or not? Are you the one that everyone asks questions of (to learn from you, or get your opinion on a design), or not? Do people seek you out for code reviews, or not? Do people need to come to you endlessly to try to figure out what your code is doing, or not? Does your code have a disproportionate number of bugs written against it? If there is a bug in your code, do the rest of your team members assign it to you because they can't begin to understand your code? And so on. There's no ego in any of that, but it is all reality(what I called the marketplace) telling you the quality of your code, in the measurable form of understand-ability, maintainability, bugginess, and so on.
Are you sure they didn't do it for performance? That is a well-known pattern for getting better data locality ("structure of arrays" vs. "array of structures").
It's cringe worthy, and working my back into it seems scarce impossible. If you drew out the program logic, it'd look like an Eldridge terror. It just isn't good code.
But yes, if you're writing War and Peace in order to parse XML, it's unlikely you're writing good code.
Also, of two okay-looking pieces of code, I noticed that the shortest is almost always the simplest. Which makes size a pretty good metric.
(Of course, this is among the least of their offenses.)
I try not to work at places like this.
Mostly I suspect that is because the software development practices such as code reviews and coding standards are actually enforced.
So... you can call it negative, I call it realistic. I'm pleasantly surprised when I discover good, well-written code, and it means my estimates can be revised downward - something everyone enjoys. Hoping for the best and getting the worst is horrible - expecting "meh" and getting a positive shock is great, but doesn't happen all that often.
I'd have loved to be at a company where people learned from each other and taught one another - imo, it's extremely rare. I've seen it a couple times in the past 15 years, but more often than not, politics and/or ineptitude takes over, and the 'learning/teaching' thing goes out the window.
As a developer, I had a technical manager over me who'd never coded. I've had a colleague who was hired to 'fix bugs', and has to watch the people who wrote the bugs go rewrite everything in to a 'version 2', rewriting exactly the same problems, because "they've been here longer".
So... yeah, companies that foster teaching/learning environments might be nice, but it takes a LOT of work to get right.
That seems like a false dichotomy. Someone who's a pollyanna even about horrendous abominations is a problem in one way, someone who's indiscriminately contemptuous of reasonably useful code is a problem in another way. Software projects (or teams, or companies) can bog down or die in more than one way. Driving off people who are doing reasonably good work is one way, tolerating unreasonably low standards is another.
And also, correct criticism is not particularly "bringing" negativity. If there is something unacceptably technically bad, and you want to point to the person or people who brought the negativity, you'd do better to point to the original creators and/or the chain of people who have signed off on it since then, rather than pointing to the person who criticizes the problem. The irreverent child did not bring the negativity to the Emperor's famous tailoring fiasco.
Someone who reasonably reliably distinguishes between good and bad is useful. Making the distinction correctly is generally much more important than the style of expression. It's easy to hire pollyannas (or, indeed, to err in the opposite direction by hiring hard-driving abrasive jerks) who don't have the tech skills to make the distinction correctly and just fall back to emoting in their preferred style. It works better to hire the smaller fraction of people who can do a good job, and who can recognize a good job. When you do that, it doesn't solve all style-related abrasiveness problems, but it does help mitigate them. By the time you've worked with someone for a while you learn to translate A's "this is unacceptable" as synonymous with B's "this is flaming rancid goat barf". (And axiomatic though it seems to be to you, in my experience saying "flaming rancid goat barf" is not useful evidence of unwillingness to learn and teach.) Both A and B are useful as long as they're reasonably reliably correct. Much bigger problems are C who says "this is a good effort" about everything, and D who flips between praise and condemnation based on issues other than technical quality (randomness, politics, mood swings, whatever).
I totally agree that not addressing issues and not bring (constructive!) criticism is a poor strategy. But your persons A and B have the same problem: they're critical without being providing any actual information. Person B just compounds it by also being a jerk.
As a programmer/businessperson, I'm not interested in making people feel good about poor quality work. I'm interested in people who want to improve themselves and the overall product, and ideally, enjoy the process. I just don't see how insulting code or people helps. I think it's perfectly possible to hold high standards on code and respectful conduct, and it's perfectly possible for people to rise to those standards, guided by constructive criticism.
Those few times make it worth to never judge too early.
Blindly assuming you know better is arrogant and will inevitably lead to problems. Discussing the underlying reasons will almost always teach you something.
I'm talking about horrors such as (this was real, production code):
bool flag = true;
if (var1 == const1)
{
if (var2 == const2)
{
// quite a lot of code
flag = false;
}
}
if (flag == true)
{
// a little piece of code.
}
if (var1 != const1 ||
var2 != const2)
{
// a little piece of code
}
else
{
// quite a lot of code
}
I'm not disagreeing on the notion that there is some shit code in the world. Of course there is. But if anyone thinks that all or most code is shit, it often says more about the speaker. And I don't mean this as a personal attack on anyone, as it is possible that someone is in particularly dire code straights, but by and large the people who I've known who think all code is shit tend to be of questionable talent.
I have a friend who is constantly regaling the horrors they meet on the roadways because, in their opinion, everyone is a shit driver. Only it's my friend who is the shit driver, and their reactionary, panicked driving technique puts them in such constant peril that they can only imagine that everyone else is to blame.
Bad driver stereotypes piss me off because they often work under the assumption that cautious drivers are bad drivers and aggressive drivers are good drivers. Hell I bet Asian women are really the safest drivers.
So, while there are ways to make code so short that it becomes incomprehensible (code golf?), most of the time, less code is almost always a good thing. A case in point would be the factorial in Haskell:
fac i = product [1..i]I'd say its appropriate to call 'most/typical code' average code, not shit.
"Everyone is a shit driver" claims almost universally come from terrible drivers: When you have no situational awareness and aren't actively predicting the behaviors of drivers around you, and you don't have confident control of the tools at your disposal, every move that other drivers make seems dangerous and scary, needing panicked reactionary responses. Every trip is a perilous journey with tales of imminent death.
I honestly feel the same about people who walk around declaring all code shit. People who aren't competent with their development tools, can't naturally trace code and truly understand functionality, and can't adapt to different styles and era of code tend to be the ones, in my experience, that declare all code shit.
I would suggest that this indicates that your figurative use of "shit" is not the common figurative use of the term in the phrase "shit code", which is impairing communication.
Most of my code is shit probably by everyones definition. So I try and write as little as possible to solve the problem. If I spent the time required to make all of my code non-shit (not good, but non-shit) then I would get very little done.
It would be nice if google wave didn't tank, or this discussion board was scriptable by the end users because I would love a sidebar where we could agree on the definitions of terms under discussion.
Due to the lack of attention, willful or otherwise, most conversations online end up talking _past_ or _at_ each other and not to.