O'Reilly Site Lists 165 Things Every Programmer Should Know (oreilly.com)

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

Comments

Re:#1 Don't read O'Reilly books

[Anonymous Coward]

Why?

Concerned when the first entry is wrong

[Anonymous Coward]

The first entry is for Abstract Data types, but the entry http://programmer.97things.oreilly.com/wiki/index.php/Abstract_Data_Types clearly refers to polymorphism or perhaps even Duck Typing.

I pretty sure that the idea of an Abstract Data Type pertains to the idea of a implementation of Tree / List / Stack independently of the object that is being actually implemented. In this case the concept of a List may be implemented with an Array backing store, a Linked List, a Doubly Linked List etc. You can swap in/out the implementation of the list in such as way as to best suit your use/needs of List type. The List is the abstract data type. Customer/Supplier in the example is nothing like this.

Sigh... Something was lost to developers when developers no longer had to LEARN how use pointers properly, and all the extra learning that was required when developers had to learn how to implemens these Abstract Data Types

Re:Concerned when the first entry is wrong

[K. S. Kyosuke]

I'm pretty sure you're at least partly wrong. As for abstract data type, quoting Wikipedia:

In computer science, an abstract data type (ADT) is a mathematical model for data types where a data type is defined by its behavior (semantics) from the point of view of a user of the data, specifically in terms of possible values, possible operations on data of this type, and the behavior of these operations.

What this *practically* meant in, say, Modula-2, was that the programmer of the ADT implemented the logic of the data type in a separate module that hid the "low-level" implementation details, as opposed to exposing the internal representation of the data type and letting clients manipulate its constituent parts "by hand". Exported functions defined the possible values, operations, and their behavior.

What this means in *contemporary* languages is that you *do* use polymophism. Or, more specifically, that an object interface represents what the exported module signature represented in Modula-2. Of course, the added bonus here is the ability to swap the concrete implementation without having to import a different module. But the main idea behind ADTs was that even if you have a single implementation, its details are confined to a *single* place.

As to the gibberish about pointers, programming of large systems requires some amount of abstraction and *desiring* to not have to implement these abstractions is stupid, stupid, stupid. You don't want clients to violate the consistency of your data structures. That has *nothing* to do with whether or not the clients know how to use pointers. They most likely do, and they may be using pointers to implement their own ADTs on top of yours, but there's absolutely no sense in making them re-implement the behaviour of your operations in a dozen different places (DRY, anyone?) "just because", not to mention future updates to your code breaking the rest.

Also, OOP's principles of 'tell, don't ask' etc. relate to the same issues that ADTs solve, despite having come from a somewhat different school of thought. Which is not surprising: many things have been reinvented several times in the course of history.

Re:Concerned when the first entry is wrong

[michael_wojcik]

What this means in *contemporary* languages is that you *do* use polymophism

No. Polymorphism is not necessary (or sufficient) for an ADT. They're orthogonal concepts.

ADTs are entirely realizable in non-OO languages. They have a long history in traditional non-OO LISP variants, for instance. Consider for example the classic text Elements of Programming Languages by Friedman et al., which introduces ADTs in the second or third chapter,[1] and refers to them extensively throughout, but uses non-OO Scheme as its illustrative language.

In C, ADTs are fully realized by pointers to incomplete structures, which make the implementation inaccessible to ADT consumers. Of course it's possible to have explicit polymorphism in C (with methods implemented as explicit function pointers rather than a vtable or other dispatch construct hidden by the language implementation), and it's even possible to combine that with incomplete structs (though invocation has to be handled by a layer which has access to the type implementation, so it's no longer an ADT at the point of dispatch). But, again, that polymorphism is orthogonal to type abstraction.

I've just skimmed Khan's ADT contribution on the website (which started this thread), and in my opinion it's not wrong per se, but it's not very good either. It does conflate polymorphism and abstraction, and wanders off the path into such matters as static versus dynamic typing. I haven't looked at the other contributions; I hope they're generally better.

[1] It's the third chapter in the '89 draft copy (with the old PL:ARI title) I have, and the second chapter in the third edition of EOPL. I assume the first and second editions are similar.

Re:Concerned when the first entry is wrong

[K. S. Kyosuke]

I actually mentioned Modula-2 (and I've gone through SICP and skimmed Friedman a long time ago). I merely hinted at implementation choices in contemporary environments. That the linked text is written in a confusing way is something I'm not questioning.

Nothing by Jeff Atwood or Joel Spolsky?!

[Anonymous Coward]

I do hope that I have merely overlooked them, but I do not see any of the works of Jeff Atwood or Joel Spolsky listed! Why wouldn't the teachings of these great masters of the craft be included?!

Re: Nothing by Jeff Atwood or Joel Spolsky?!

[Anonymous Coward]

Either they didn't want to pay the royalties, or they wanted bits from real programmers rather than self-impressed drama queens.

Lots of links to articles, phfft

[Snotnose]

Anyone wanna summarize the list so I don't have to read 160 articles to see if I agree/disagree with them?

That said, I trust O'Reilly to produce quality books. One fail (Make) in maybe 20 books I own from them is a good record.

/ The Gnu make manual is the best Make doc I've seen.

Re:Lots of links to articles, phfft

[godrik]

What ? This is slashdot! Since when do we read things before disagreeing with them?!

Re:Lots of links to articles, phfft

[Anonymous Coward]

Didn't take me long to start disagreeing with them. This one.

I'm sorry, but a program that's thousands of methods and small classes is not clearer than a program with fewer, larger, structures. Yes, write code for Humans, not machines, I agree. BUT remember your other programmers want to understand your program - not any one individual method - so making each method simple only moves the complexity into the interrelationships between methods, something considerably harder to understand.

(The real failures when other people edit my code usually come in not understanding how classes inter-relate and the layers of the program - the architecture if you will. And at the moment, the only real way of communicating this? Comments describing the architecture.)

And, do comment your code - not 'as little as possible', but not 'what's obvious from the code'. Remember what's obvious to you might not be obvious to someone else -- write code for humans, not machines. I'm really REALLY not sure that creating another class to hold four parameters for one method is any clearer than just those parameters - especially since I work in languages that support named parameters anyway (a much neater solution)).

The dead giveaway that this person is full of it is their lack of justification - explain to me WHY the "rule" exists..

(NB: This is really a collection of 97 micro-essays -- it has, actually, 97 authors - so each author is different.)

Re:Lots of links to articles, phfft

[DontBeAMoran]

I don't even know what the hell you guys are talking about, but I disagree!

Re:Lots of links to articles, phfft

[Northdot]

The tiny-functions-are-panacea meme has got to die, for exactly the reasons you stated. It's trading function simplicity for system complexity. And all of those thousands of needless function interfaces you need to maintain, refactor, and potentially unit test... it's just crazy town.

Ironically the book "Clean Code" promotes this stylistic disaster. Yes each function might be "clean" taken by itself, but the system as a whole is anything but.

Re:Lots of links to articles, phfft

[geoskd]

I'm sorry, but a program that's thousands of methods and small classes is not clearer than a program with fewer, larger, structures. Yes, write code for Humans, not machines, I agree. BUT remember your other programmers want to understand your program - not any one individual method - so making each method simple only moves the complexity into the interrelationships between methods, something considerably harder to understand.

What the author was implying is that you should take relatively straightforward components of a function and break them out as their own sub-functions with a very descriptive name, especially the inner workings of nested loops. If you take the inner loop and replace it with a function call that describes what the inner loop does, then your outer loop actually gets much easier to read, as it does not have the distraction of the gritty details of how the inner loop performs its duties. With properly written sub-functions, you can simply read the name and understand what it is doing without having to actually read the function at all. I have personally done code reviews on code that has been re-factored in this fashion, and the readability of the code is night and day.

Re: Lots of links to articles, phfft

[Anonymous Coward]

... you can simply read the name and understand what it is doing without having to actually read the function at all.

Jesus Christ. I sure hope you don't actually make such assumptions while working on any production-grade code...

Re:Lots of links to articles, phfft

[russotto]

Exactly. My complaint is it's going to take me forever to come up with 165 well-thought-out snarky responses to all of these things.

Re:Lots of links to articles, phfft

[AHuxley]

"Know Your Language"
http://programmer.97things.ore...
"Learn the Platform"
http://programmer.97things.ore...

Re:Lots of links to articles, phfft

[JustAnotherOldGuy]

Anyone wanna summarize the list so I don't have to read 160 articles to see if I agree/disagree with them?

1) Don't do stupid shit.

2) Think ahead.

3) Don't reinvent the wheel.

Re:Lots of links to articles, phfft

[Anonymous Coward]

That makes sense if the inner loop is quite large, but not so much if it is small, or the inner and outer loop are very similar (e.g. obviously just looping over a multidimensional array). It doesn't take much for this idea to make code very difficult to read and maintain. I had to take over some code that automated some equipment and at some point we changed the equipment such that a default setting was no longer appropriate. It took two people way too much time to dig for where that default value came from, finding it was some 30+ functions deep for a program that basically: loads two different settings files, setups up a device, reads data from device, then saves it. The code was refactored and 500+ functions reduced down to about 60 functions, none more than a page long. Even with descriptive names for functions like DefaultValueForSettingFoo, it didn't help when a certain condition at a later in function LoadValueForSettingBar sets a different default value to Foo.

Functions are best when done for reuse. Occasionally a single use function has its place when you're segregating very different types of code. But going to the point of many functions having one or two lines of code then a call to another function that is used nowhere else, you end up with spaghetti code.

Re:Lots of links to articles, phfft

[WaffleMonster]

What the author was implying is that you should take relatively straightforward components of a function and break them out as their own sub-functions with a very descriptive name, especially the inner workings of nested loops. If you take the inner loop and replace it with a function call that describes what the inner loop does, then your outer loop actually gets much easier to read, as it does not have the distraction of the gritty details of how the inner loop performs its duties. With properly written sub-functions, you can simply read the name and understand what it is doing without having to actually read the function at all. I have personally done code reviews on code that has been re-factored in this fashion, and the readability of the code is night and day.

I disagree. Commenting a code block accomplishes the same thing and "distractions" reasoning for taking up a few more lines on a page is of unconvincing value and probably dangerous. What IDE does not allow you to collapse by scope? For all you know someone may discover an important side-effect by actually noticing structure of intervening code. When you replace comments with function names then function names also risk becoming as stale and dangerous to believe as comments.

My personal view organizing code generally to maximize readability at the expense of minimizing complexity leads to unnecessary accumulation of debt that will ultimately be paid back with interest in any non-trivial project.

Re:Lots of links to articles, phfft

[Tough Love]

If you take the inner loop and replace it with a function call that describes what the inner loop does, then your outer loop actually gets much easier to read...

Nice idea when things happen to factor that way. But often they do not, and the additional glue you need to factor out the inner loop adds more obfuscation than it removes. The takeaway is, just don't be mindless about factoring techniques.

Re:Lots of links to articles, phfft

[Anubis IV]

Exactly. At the end of the day, legalistically following most "rules" will result in poor code. A good software developer understands when it makes sense to have a longer function or shorter one. They understand when and how to break functionality out. They understand when shorter code is easier to maintain and when longer code is easier to maintain.

It's hard to point to any particular rule and say that it ALWAYS holds true, though it's easy for us to cite examples of rules that should've been followed in particular situations (e.g. the 12,000 line function I once saw that could've been done in about 200-300 lines, had the guy broken the repeated functionality out into other functions; devs creating smaller functions without regard for their interplay, resulting in a stack overflow because they used the functions recursively without realizing it).

Re:Lots of links to articles, phfft

[Anonymous Coward]

I (the previous AC) think we're actually disagreeing then. I don't think that rule should be applied except in very specific and uncommon situations. There is a difference between a rule that works most of the time but shouldn't taken to the extreme, and a rule that should almost never be used because it is already an extreme application of something that should be rare.

Re:Lots of links to articles, phfft

[Pseudonym]

I'm sorry, but a program that's thousands of methods and small classes is not clearer than a program with fewer, larger, structures. Yes, write code for Humans, not machines, I agree. BUT remember your other programmers want to understand your program - not any one individual method - so making each method simple only moves the complexity into the interrelationships between methods, something considerably harder to understand.

Actually, I agree with the author on this one, but the title is wrong. It should be something more like: "Write your code under the assumption that dozens of mediocre programmers will be eventually responsible for maintaining it."

This "thousands of 15 line methods and small classes" approach is the only way that we know of, so far, to scale up codebase to dozens or even thousands of mediocre programmers. It sucks, but really good programmers are hard to find.

Re:Lots of links to articles, phfft

[Anonymous Coward]

I actually read that "clean code" book. 15 Lines would be fine, but the book actually says that 3 lines is the absolute longest a function is allowed to be. In fact it then goes on to say that case statements are always more than 3 lines so you should never use them.

Re:Lots of links to articles, phfft

[Tranzistors]

Don't do stupid shit.

I am sure this is a sound advice that actually helps people improve their behaviour. </s>

Re:Lots of links to articles, phfft

[Anonymous Coward]

i get what you're saying, but: You write 10 small functions and then have another function that ties them all together. Problem solved, your system isn't any more complicated and you can still easily unit test the smaller functions, understand everything more quickly, and re-use them in other places instead of copying/pasting your logic around.

Re:Lots of links to articles, phfft

[TheRaven64]

Neither extreme is a panacea, but modern compilers are good at inlining, so there's little performance difference between the two and small functions do make sense when each is an individual step in the algorithm. The function that calls a number of small functions then reads like an abstract description of the algorithm that you're implementing and people only need to see the details if they want to. What you really want is a literate programming system where you can embed default detail levels into the code and have the IDE so that when someone opens your code for the first time they just see comments describing the steps of the algorithm and high-level flow control, but can easily unhide any of the details. Small functions give you an approximation of that.

Re:Lots of links to articles, phfft

[Anonymous Coward]

I'd paste some completely offtopic random rant here, but no-one would get the joke.

Re:Lots of links to articles, phfft

[allcoolnameswheretak]

I don't disagree with that one.

Picture a program as a huge collection of LEGO bricks and pieces, and understanding the program implies understanding how the LEGO parts are being used.

What is easier to understand, one huge box full of LEGO bricks along with a very long instruction manual explaining all of the contents, or having the LEGO bricks neatly divided into smaller packages along with shorter instructions that focus on the contents of each individual package?

Of course, the big advantage of the latter is that you can focus on smaller, individual components and understand the whole program step by step, getting more familiar as you go.
With the former your are faced with the whole big chunk at once - all or nothing. What would you prefer?

Re: Lots of links to articles, phfft

[Dog-Cow]

You don't understand the difference between what and how, so you're opinion is worth less than nothing. You actually owe people for the pain of reading your comment.

Re:Lots of links to articles, phfft

[grep -v '.*' *]

Anyone wanna summarize the list so I don't have to read 160 articles to see if I agree/disagree with them?

1. THE ROBOTS ARE COMING -- find a different job.

Re:Lots of links to articles, phfft

[vtcodger]

You're in luck. If you actually open the link, there seem to only be 97 of them. Maybe a few more routine actions will get the list down to something more tractable. Maybe 3 or so.

Re:Lots of links to articles, phfft

[allcoolnameswheretak]

Programmer is the safest job. Somebody has to program the robots.
When the robots learn to program themselves, well, then we have reached the end of human civilization.

Re: Lots of links to articles, phfft

[Anonymous Coward]

Way to miss the point. It isn't just the what and the how that are the issue here. The issue is that he's assuming what the function does based on its name alone, without actually checking what the code actually does. Professional programmers should never do what he is suggesting. His advice is total rubbish. You should not be promoting his broken and harmful practices.

Re:Lots of links to articles, phfft

[SharpFang]

You write 10 small functions, each a small non-trivial piece of code. You write one small function that binds them together. Next person after you needs to hunt around 11 files in the code to determine how that works and why it doesn't work to specs, instead of having the whole "device" right in 2-3 screens. Never mind if that's 10 + 1. What if it's 1000+100+10+1?

Or you have 6 different places where given piece of data is used, and it's used in 6 different slightly different variants. So you create these 6 methods - say, getters that in absence of valid data either supply a default, or throw an exception, or request the data and block until provided, or bypass the cache, or provide the data if not manually overridden, override value otherwise... and you write a 7th function, and now you need to dig through all the variants, only to find none of them suits your needs and you need to write a seventh one. And it's about impossible the next person will need your specific variant, but still - you moved the adaptation of input out of logic, and put it next to output of data storage. Would be a laudable endeavor... if it wasn't so counter-productive!

Re: Lots of links to articles, phfft

[SharpFang]

You don't understand the difference between what a function claims to attempt to do versus what it actually achieves. You have no business in IT.

int returnRandomInt(int max)
{
            return 4;
}

Re:Lots of links to articles, phfft

[JustAnotherOldGuy]

Don't do stupid shit.

I am sure this is a sound advice that actually helps people improve their behaviour. </s>

It's helped me and countless others, but it won't help the terminally stupid.

Re: Lots of links to articles, phfft

[Anonymous Coward]

The issue is that he's assuming what the function does based on its name alone, without actually checking what the code actually does.

I'd argue that, if I see something like this:

"Integer elapsedDays = elapsedTimeBetween(Date startDate, Date endDate)"

It'd be reasonable to assume that I'm going to get back the number of days elapsed between startDate and endDate. Now, if I'm seeing behavior in my code where the elapsedDays value is misbehaving somehow, then I need to investigate *what* that code actually does. If I'm seeing behavior completely unrelated to this value, then it's a good bet to assume that:

a) The function is returning an integer value which represents elapsed days between a specified start and an end date, as its name and param list suggest;
b) The problem is NOT inside that function;

Now, if I go look at elapsedTimeBetween(), and discover that it's got half a dozen side effects and returns a string that includes the user's password hash, then sure, that's a major problem. But if you can't look at that code and rely on it doing more or less what it says, then your code is not "production-grade" in the least to begin with, and you need to heavily rewrite it, or stop being a programmer.

The point of having well-named, small functions is that when you're investigating an issue, you don't have to read through the entire control flow of the program to understand where things are going wrong - you abstract away functionality in chunks so that you can quickly zero in on the appropriate level of abstraction to determine where your bug is.

Or, you could just inline the whole fucking thing and guarantee you'll never be promoted, never find another job, and never do anything but maintain your own shitty, bit-rotting code.

Re: Lots of links to articles, phfft

[Anonymous Coward]

It takes a human to come up with something as inefficient and terrible as javascript, and then sell it as the new best way to develop software so there is still need for more RAM and faster CPUs.

Re:Lots of links to articles, phfft

[Anonymous Coward]

Bad example. Any serious player/user of LEGOs understands it's far better to root around in an unsorted box of bricks than to simply pick from sorted bins. The former isn't more efficient but, much more fun.

Re:Lots of links to articles, phfft

[Anonymous Brave Guy]

You write 10 small functions and then have another function that ties them all together. Problem solved, your system isn't any more complicated

Yes, it is. It's more complicated by now having 11 parts instead of one, and 10 extra relationships between them.

None of the rest of your claims follow automatically just from having more, smaller functions. Indeed, the point several of us are trying to make is that exactly the opposite may be true: breaking everything down into very small functions can make code harder to understand. While the individual functions are simpler, the number of potential relationships between them grows exponentially, and those relationships may not be as transparent once you've broken everything down into tiny pieces.

Re:Lots of links to articles, phfft

[coofercat]

Oh, except for:

72. Reinvent the Wheel Often by Jason P Sage

Beware the 'catchy' titles. This one happens to sum up to "if you reuse some code, you won't have intimate knowledge of it and will just consider it a black box". It's not made especially clear why that's such a bad thing though.

Re: Lots of links to articles, phfft

[Anonymous Coward]

Actually, Parent is correct. If you assume what a function does based on its name then that can cause all sorts of trouble. The function could be mis-named, or function could have changed what it does without being renamed. You always need to look at code to see what it does as well as how it does it.

Re: Lots of links to articles, phfft

[Anonymous Coward]

Code that does something different than what the function name says is a bug. Whether the bug is with the function contents or the function name would require studying the original design and change history, but people that perpetuate the bug by pretending that the GP's approach has no place in IT, have no place in IT.

Re:Lots of links to articles, phfft

[ziggystarsky]

But, but, but...

72. Reinvent the Wheel Often

Re:Lots of links to articles, phfft

[angel'o'sphere]

Indeed, the point several of us are trying to make is that exactly the opposite may be true: breaking everything down into very small functions
That is a strawman. Nobody said very small. They simply should be small enough, that is all.

the number of potential relationships between them grows exponentially, and those relationships may not be as transparent once you've broken everything down into tiny pieces.
Then you are doing it wrong.
By "definition" a function only works their arguments and returns a result. Usually, if it is a method in a class, it does not even manipulate the attributes of its associated object.
The only relation functions have to each other is their call hierarchy, which is easy to figure and in an IDE trivial. Worst case use the debugger.

Re:Lots of links to articles, phfft

[meta-monkey]

And at the moment, the only real way of communicating this? Comments describing the architecture.

A few years back I started incorporating UML diagrams into my design process. So before I start coding I draw out the architecture of the program, and this becomes part of the documentation. I find this useful for my own planning purposes to prevent constant refactoring, and if I need to explain the program to someone else, a picture is worth a thousand words.

Re:Lots of links to articles, phfft

[meta-monkey]

That sounds retarded. I think a balanced approach is DRY. Do I ever find myself writing the same set of instructions twice? If so, make it function. Is it something that only gets written once? Inline it.

Re:Lots of links to articles, phfft

[pruss]

This works especially well in languages where you can have a function whose definition is within the scope of a function. Then all the functions are guaranteed to be together in the source, and with their containment relationships obvious to the human reader. If one changes an inner function's functioning, one only needs to check in one place--the outer function--for how this affects things.

Re: Lots of links to articles, phfft

[SharpFang]

Yes, that code is a bug.

Guess what real programmers do at least 60% of the time?

Fix bugs.

Any technique that obscures bugs is detrimental.

Re:Lots of links to articles, phfft

[Anonymous Coward]

Version control systems, unit tests, and type safety (where supported by the language). And choose good names.

Deal with it, you're going to spend the rest of your life reading lists of "tips" that contain those four.

And do your taxes before the deadline!

Re:Lots of links to articles, phfft

[Anonymous Coward]

It's bad because if you write something one way, small errors will only cause it to fail in one set of edge cases. But if you write something 10 ways, it will fail in 10 partially overlapping sets of edge cases, so you'll be able to spend 10x as much time fixing bugs, eventually resulting in 10 identical implementations that can just be reduced down to 1, requiring more time to modify and test every instance that makes use of one of them. By the end of it, you'll know the code really well and will have been able to charge 500 hours for a 20-hour task. But who can put a price on knowledge?

Re: Lots of links to articles, phfft

[Chris Mattern]

Yes, that code is a bug.

Hey, that four was generated by a fair die roll and is guaranteed to be random!

Re:Lots of links to articles, phfft

[Anonymous Coward]

#3 is actually the hardest for new programmers. To this day I start writing something in, say, python and find out that it's been done, posted on github, and abandoned years ago.

Re:Lots of links to articles, phfft

[Anubis IV]

I'm not sure if we are or aren't disagreeing. The point I was trying to make is that we shouldn't unquestioningly follow rules for their own sake. Instead, we should follow them inasmuch as they help us to write more maintainable code. At the end of the day, we want maintainable, well-designed code, not a mess of code in a single function, nor a mess of code scattered across too many functions.

As a general statement, I run into more developers who would benefit from the "keep functions short" rule, just because there's a tendency (particularly among novices) to sit down at a keyboard and start typing until the code "works", rather than starting with a design and then building code to that design. For those developers, the "keep functions short" rule forces them to take stock early in the process and realize that they need to think through the design of their code, but for more experienced developers, I should hope they know when to disregard the rule because it'll make the code less discoverable.

Re: Lots of links to articles, phfft

[Anonymous Coward]

Ok. You are obviously in over your head programming. Any IDE will prevent you from 'hunting' around. I know your type. You create monolithic methods that contain local, business, and data logic in it. Then the same data logic is copied and payed into 6 other functions that do the same thing. Any business rules update requires much more work.

Or maybe I'm exaggerating like you. Maybe not. You need to follow what smarter people have figured out. And if you think you are the smartest in the room, well that's a sign for you.

Re:Lots of links to articles, phfft

[Anonymous Brave Guy]

That is a strawman. Nobody said very small. They simply should be small enough, that is all.

Unfortunately, that's not true. Plenty of people do openly and sometimes rather strongly advocate extremely short functions, including Robert Martin, whose book was mentioned back up the thread. Even the original point that was linked at the start of this thread suggests an upper limit of 15 lines, which is far too short for a lot of useful algorithms.

By "definition" a function only works their arguments and returns a result.

In a pure functional language, that is true. Almost anywhere else, it is not, because functions can have side effects, often including interacting with various forms of state kept outside the function.

Usually, if it is a method in a class, it does not even manipulate the attributes of its associated object.

If it's not doing anything with the attributes of its associated object, why is it a method on that class in the first place? This makes little sense, unless you're talking about languages where all functions live on some class and so sometimes classes are basically just used as namespaces with no state.

The only relation functions have to each other is their call hierarchy, which is easy to figure and in an IDE trivial. Worst case use the debugger.

Again, that only really works in certain types of programming language, though. In languages where you can pass functions around like any other value, or even just C-style function pointers, you have a level of indirection that makes systematically identifying all potential calls to a function significantly harder. If your functions really do represent self-contained concepts with a useful amount of abstraction, the trade-off is often still worth it, but if you're just breaking a relatively long function into smaller parts because of some arbitrary limit, it's a different story.

Re: Lots of links to articles, phfft

[Anonymous Coward]

Agreed. There is coding it. The creation. Debugging. Testing. Maintaining. All of these benefit significantly from clean code principles.

Creation of utility classes help abstract code that can be reused Amung projects. Four on four or all languages this is called the common library. System. Whatever.

The real problem here is all of these novice to someone experienced programmers reached a point where they think they are smart enough to start thinking they can outsmart the language designers. Most of us are not. I don't know how many times I've heard somebody pop off in an interview saying they could design a faster search or sort algorithm programmers reached a point where they think they are smart enough to start thinking they can outsmart the language designers. Most of us are not. I don't know how many times I've heard somebody pop off in an interview saying they could design a faster search or sort algorithm. Implying they are smarter than a team of people. Well this is true for specific cases, the principles used to redevelop a custom version will still be exactly the same.

  People keep asking why reinvent the wheel? You don't need to. If people followed some sort of common design instead of going crazy in their spaghetti head things would be more simple to take over someone else's project.

  But not everybody even has the capability to understand and think like this and therefore cannot design a system that is coherent following those principles.

  In any thing that we do in life, abstraction makes a natural science. Things are separated naturally in nature. And everything that we use is obstructed in someway. Pam has a closure a pink container and a button. A pencil has an enclosure, some blood, and an eraser.

  These are separate and abstracted things. Same with the car. Same with the tree. Same with a flower. You can see them all as one or you can see them as their individual components .

  The scientific mind can see both. Fuck you all.

Re: Lots of links to articles, phfft

[Anonymous Coward]

That's ridiculous to the point that I think you've misunderstood something.

Re:Lots of links to articles, phfft

[avandesande]

It also helps to get old and have your memory fade. If you don't follow good naming conventions it is hard to understand what you wrote yesterday.

Re:Lots of links to articles, phfft

[avandesande]

Change the function name?

Re:Lots of links to articles, phfft

[angel'o'sphere]

Even the original point that was linked at the start of this thread suggests an upper limit of 15 lines, which is far too short for a lot of useful algorithms.
This is a matter of taste and experience.

I never saw a reason for functions that long. However there is no hard limit for me. If I can not cut out a function with a useful name, then I keep the big function.

Almost anywhere else, it is not, because functions can have side effects, often including interacting with various forms of state kept outside the function.
Emphasize on "can". But they should not. So you are arguing because you write bad code (functions with side effects) it is pointless to write shorter functions?

This makes little sense, unless you're talking about languages where all functions live on some class (in most modern languages that is the case) and so sometimes classes are basically just used as namespaces with no state.
Because often it makes no sense to move such functions into classes with no state ... circular argument ... I'm still talking about ordinary classes with state and methods. But some bigger algorithms might be divided into smaller functions. The algorithm modifies state of the object, the smaller functions not necessarily.
When an algorithm is modifying the state of an object, and hence is a method, then I keep the "sub functions" usually as methods, sometimes static, in that objects class. Instead of moving them into utility classes "for name space purpose" ...

but if you're just breaking a relatively long function into smaller parts because of some arbitrary limit, it's a different story.
We don't do that because of an arbitrary limit, like 15 lines. We do it to improve readability and maintainability and on top of that: testability.

A complex algorithm that is divided into several small(er) functions can be tested by testing the functions individually. A big function can only be tested as a block. And then show me your test and proof that every branch in the function is at least tested once ... if you are smart you are using a coverage analyzer for that ;D

Historically the idea of short methods comes from SmallTalk (and/or Lisp/CLOS), where 5 lines are usually expressing much more code/business logic than 5 lines of lets say C. On top of that in early IDEs - yes, IDEs, not vi/emacs - the code editing widget was rather small. Think about the first Apple Macintoshs, they had a 9" screen if I recall correctly. With a class browser on top and some inspectors on one side, you basically only had a 10 lines * 50 chars code editing widget. However that widget did not show the whole file, but just the selected method in the class browser.

Bottom line it comes down to a simply question of coding approach: do you often copy/paste code? So that a function starts with 3 times 2 lines of identical code but different variables? Then why not placing those 2 lines into a "function" and just call it 3 times? And no: 3 times copy pasting the two lines is not faster than writing it once and then use the IDEs refactoring "extract method".

Or do it as I do: just call the non existing function and answer the IDEs question: "should I auto generate the function for you?" With "yes" and you are automatically with your curser inside of the function and write your code.

Re:Lots of links to articles, phfft

[Bengie]

The "Clean Code" guy makes a lot of extremist devil's advocate assertions with the intention of making your think about clean code in a purist way. Of course it is up to you, the reader, to apply his wisdom in a practical manner. His most useful chapters are about code smells. They are the most practical. Kind of "If you see this, stop and think about why, and if it should be done this way or is there a cleaner way".

Re: Lots of links to articles, phfft

[unrtst]

Hey, that four was generated by a fair die roll and is guaranteed to be random!

It still has a bug, since it takes a "max" argument. Correct code should be something like:
int returnRandomInt(int max)
{
        if (max > 3) return 4;
        return 0;
}

Re: Lots of links to articles, phfft

[Anonymous Coward]

See here. It is so obvious who has gone to school and who has not. This guy though he tries, can't even use the terminology to communicate precisely because he does not know it.

Re: Lots of links to articles, phfft

[Anonymous Brave Guy]

Which of us do you think hasn't gone to school and doesn't know the terminology we're using? Obviously we appear to disagree on this issue, but I don't see anywhere that the meaning isn't clear on either side.

Re:Lots of links to articles, phfft

[Anonymous Brave Guy]

I never saw a reason for functions that long.

A data processing pipeline with more than a handful of steps?

A subgraph match that needs to check for more than a handful of nodes and edges?

Those are the first two that come to mind, because I happened to work on both of them today.

Emphasize on "can". But they should not. So you are arguing because you write bad code (functions with side effects) it is pointless to write shorter functions?

If you're advocating being careful about where side effects happen, you're preaching to the choir. However, I have not yet been made god-emperor of the universe, so sadly I don't get to impose my preferred design style on everyone else and sometimes have to work with code written by foolish mortals. Also, I have yet to encounter a mainstream programming language that is actually good at supporting this goal.

We don't do that because of an arbitrary limit, like 15 lines. We do it to improve readability and maintainability and on top of that: testability.

The first part of this, about readability and maintainability, is just begging the question.

As for the testing part:

A complex algorithm that is divided into several small(er) functions can be tested by testing the functions individually. A big function can only be tested as a block. And then show me your test and proof that every branch in the function is at least tested once ... if you are smart you are using a coverage analyzer for that ;D

Merely breaking out parts of the code into smaller functions doesn't reduce the complexity of the decision tree, so if you want to argue for comprehensive branch coverage then you need just as many tests either way unless you're immediately reusing your smaller functions (and I don't think we're talking about that sort of scenario here).

In my experience, attempting comprehensive branch coverage as a strategy for writing unit test suites is usually futile and almost always inefficient anyway. There are many other ways to try to prevent errors that are usually more effective.

Re: Lots of links to articles, phfft

[SharpFang]

Oh, the IDE can only go so far. It helps, but once you have the relevant logic spread over 20 or more files, no IDE will let you grasp it all.

I tried following what "smarter people" created before me. Preparing for every possible eventual expansion of the system - adding new business logic algorithms, new types of input data, new variants of output, dynamic switch of dataset and algorithm mid-execution, massive parallelism, with a lot of cross-thread communication and clever automatic scheduling of tasks. They had been mucking around with it for 3 years, making a system that was very elegant - and completely useless.

It appeared the underlying system requires everything to be single thread, running under RTOS, because critical operations were not being completed on time and race conditions resulting from the underlying system design abound. And the deadline was in half a year.

All that fancy work had to be scrapped and written from scratch, in a much simplified form only sparsely utilizing scraps of old logic. The whole fancy broad class structure with deep inheritance trees and clever class switch-over mechanism was scrapped, replaced by a couple of classes with inheritance through composition. The smart scheduling was at the core of race conditions; replacing it with two trivial, rigid lists of jobs (realtime, and background) solved the issue.

And it's now some 6 years. The system works fine. Extra business logic algorithm had to be added once, it didn't take more work than it would before. Cosmetic changes of logic happen every couple of months, and need to be applied in three places instead of former one. The idea of business algorithm switch-over on the run appeared to run afoul of safety regulations, the on-the-fly change leading to transitions not allowed by law. The dataset switching, performed maybe once a year, requires extra two minutes of work versus what it was originally. Its structure was only ever expanded, which meant business logic also only was expanded occasionally.

Meanwhile, an area that lay fallow during the first version - interaction with external systems - underwent massive expansions. The fancy structure wouldn't help one bit with that. The range of systems that came up, what they did and what they needed was so wildly varied there's no way any preconceived structure to accept them would ever stand a chance. The lack of such system appeared a blessing, because adding them was straightforward; wherever they had to slice right into heart of the business logic in a completely new way, there was no struggle to break through extra abstraction layers; a single if() operating on easily accessible superglobal replacing twenty new methods to access areas previously isolated from the rest.

The bottom line is that you can't foresee every way the system may be modified or expanded, and making the system extendable in a way you guessed would be common may very well appear both completely useless (the system will never be extended that way) and thoroughly detrimental to expansion in a way that is required. Keeping the system SIMPLE from moment one, and instead of trying to account for every possibility, only doing what it needs to do in the simplest way it can do, is a much better approach to making it easy to expand. And - surprisingly, maybe - makes debug easier too.

Re:Lots of links to articles, phfft

[angel'o'sphere]

A data processing pipeline with more than a handful of steps?

A subgraph match that needs to check for more than a handful of nodes and edges?

I would not know why both can not be expressed with a set of small functions.

The first part of this, about readability and maintainability, is just begging the question.
Perhaps your mind works different than mine. For me it is obvious that a set of smaller functions is easier to understand and maintain than a big one.

Merely breaking out parts of the code into smaller functions doesn't reduce the complexity of the decision tree, so if you want to argue for comprehensive branch coverage then you need just as many tests either way
Obviously. But now I don't have one complex test case that tests a big function, but a set of very simple test cases.

In my experience, attempting comprehensive branch coverage as a strategy for writing unit test suites is usually futile and almost always inefficient anyway.
Some customers require that.

I usually never write unit tests, I only write User Acceptance Tests (Story or UseCase/Scenario based), high level System Integration Tests and use a coverage tool. OTOH if I was writing a compiler I likely had thousands of unit tests.

Nevertheless I would prefer to write "easy" tests on small functions than on big ones, and if my job was to test big functions: I would refactor them imediatly into small ones.

Re:Lots of links to articles, phfft

[Anonymous Brave Guy]

I would not know why both can not be expressed with a set of small functions.

Well, what would those small functions be? Suppose we've got a data processing pipeline that essentially looks something like this:

valueA, valueB = step1(inputA, inputB, inputC)
valueC = step2(valueA, inputD)
valueD, valueE = step3(valueB, valueC)
...
resultA, resultB = step20(valueX, valueY, valueZ)

It probably makes sense to break out each individual step into its own function, but if your algorithm has 20 steps, each of which might need some input data from various earlier steps, what advantage is there in breaking this function down any more? It's just fundamentally a long sequence of operations.

The other example I gave is a slightly different case, but a similar conclusion. The general subgraph isomorphism problem is NP-complete, but you probably know more about your underlying data in realistic situations, so matching algorithms often wind up being some sort of deeply nested search with the order of tests determined heuristically. The similarity to the previous example is that again each level of the search might need context from various outer levels. So again, what is gained by breaking out the inner loops into their own functions here? They have no inherent meaning without that context, so it's not as if they're going to be reusable or they're going to represent some useful abstraction with a meaningful name. It's just splitting up code that is fundamentally related to avoid some dogma about deep nesting being bad.

I don't know what your background is or whether you've ever worked in the kinds of fields where these sorts of situation tend to come up. A lot of programs only need very simple data structures and algorithms, and if that's the kind of code you tend to work on then maybe what I'm saying just looks like contrived examples. All I can say is that I've worked on many projects over the years that do have need of more sophisticated data structures and algorithms than, say, typical business management software, and I've seen plenty of code where having functions of 50-100 lines or longer is entirely reasonable. Obviously I'm not talking about all of the functions, or probably even most of them, but I would argue that the important point is whether each function provides some clean, coherent packet of functionality, not whether it's 5 lines long or 105.

Perhaps your mind works different than mine. For me it is obvious that a set of smaller functions is easier to understand and maintain than a big one.

From the discussions so far, I suspect we've just worked mostly on different types of software. In some cases, I do write a lot of quite small functions. But I don't do that because being small is good, I do it when it happens to need only a few lines of code to represent whatever concepts I'm working with at the time.

When I see people like Robert Martin making sweeping generalisations about keeping functions very short or keeping under N parameters or whatever, and particularly when those people also imply that anyone whose code doesn't follow their rules is somehow a bad programmer or unprofessional or whatever insult they're hurling around this week, I feel a bit like a guy modelling the aerodynamics for a supersonic jet plane whose ten-year-old kid thinks wing design doesn't really matter because he can get enough lift already with his paper plane.

Re:Lots of links to articles, phfft

[angel'o'sphere]

Well,
As I mentioned before:
If you can give each step a meaningful name, I would prefer to have it in its own function, instead of a comment on top of it.
If such names are not easy to find a long function is probably simpler.

Re: 1. Rust ... 165. Rust

[Anonymous Coward]

So 6 of the rules are Rust?

Pair Programming

[Anonymous Coward]

Not sure "pair programming" qualifies as something every programmer should know. Though perhaps every programmer should know that a few programmers are rather fanatical about it.

Re:Pair Programming

[quantaman]

Not sure "pair programming" qualifies as something every programmer should know. Though perhaps every programmer should know that a few programmers are rather fanatical about it.

Knowing it doesn't mean you need to practise it.

The list is basically a giant list of suggestions and perspectives, not every one is applicable to every situation, but knowing the list means you have a much better chance of knowing the ones that are applicable to your situation.

Re:Pair Programming

[TechyImmigrant]

Pair programming sounds horrible and I'm glad I don't have someone staring at my screen while I'm trying to slack off and read Slashdot.

Re:Pair Programming

[Anonymous Coward]

... trying to slack off ...

It's called, interrupting job tasks to prevent boredom and burn-out.

... read Slashdot.

That's gaining external perspectives on important issues; which is the very point of 97 Things Every Programmer Should Know.

Re:Pair Programming

[__aaclcg7560]

Pair programming works better when you have the opposite sex sitting on your lap.

Re:Pair Programming

[ockegheim]

Not if they're a 3yo asking for a video.

Re:Pair Programming

[Anonymous Coward]

3yo? hmm... I prefer a little older but whatever tastes are different...

How to kiss ass?

[Anonymous Coward]

Did "how to kiss ass?" make the list?

clean up trust someone help someone

[Anonymous Coward]

at least one, that's the spirit.. cease fire stand down.. hugs not thugs.. no bomb us more mom us.. 'they lay down their weapons, stand hand in hand, & gaze into the heavens...

TL;DR

[Anonymous Coward]

The only list over 100 I will read is something about world's sexist ladies

Also #1 is programming can bring you sexy lady. It's best motivation.

Regards biology pro

Unix Tools vs IDE

[Crashmarik]

Depends which do you think you can recreate faster as you need them.
Small Unix Tools using the IDE
or the Large IDE using small Unix tools.

Re:#1 Don't read O'Reilly books

[Anonymous Coward]

#2A. If you have to ask why not to read O'Reilly books, you are not a programmer.

O'Reilly Posts One Weird Trick Every Programmer

[Proudrooster]

Doctors and IT Managers hate him. O'Reilly Posts One Weird Trick Every Programmer Should Know....

Don't ever give a Nigerian Prince your bank routing number. Oh, and use MVC (Model View Controller).

Re:O'Reilly Posts One Weird Trick Every Programmer

[JustAnotherOldGuy]

Oh, and use MVC (Model View Controller).

No, never, ever. Not even at gunpoint. Not even if you were holding my wife and kids at gunpoint.

MVC has caused more heartbreak and aneurysms than tequlia and bacon combined.

Re:O'Reilly Posts One Weird Trick Every Programmer

[MrKaos]

Oh, and use MVC (Model View Controller).

No, never, ever. Not even at gunpoint. Not even if you were holding my wife and kids at gunpoint.

MVC has caused more heartbreak and aneurysms than tequlia and bacon combined.

Ok, why?

Re:O'Reilly Posts One Weird Trick Every Programmer

[Pseudonym]

Number 38 will shock you!

Re:O'Reilly Posts One Weird Trick Every Programmer

[SharpFang]

It's often used for systems that are way too small to ever need the resulting complication. And when the system needs to be extended, it frequently appears what it needs to work with doesn't fit the current implementation in the least, and instead of writing a trivial interface, you are forced to massage the MVC engine/framework into fitting the new thing.

It's a decent system if you know majority of requirements a'priori, the system is big, and can only grow in well understood ways.

If the system is to grow a lot from a small root in ways you can't even roughly foresee, MVC feels like the smart way to make it flexible and easy to expand. Until you encounter requirements that are completely orthogonal to current design, say, deadline/realtime reply requirements, massive parallellization, making the system distributed, or porting to small embedded.

Adding an extra page with some report, or a summary, or shuffling a piece of UI into a different UI branch is nice and clean in MVC, and these are the typical expansion types you foresee. But if it's something like mentioned above, you're suddenly in for a long haul and a lot of heartbreak. Modifying stuff within a framework is nice. Modifying the framework engine - not quite so. And MVC frameworks tend to be heavyweight and very complex; in a lot of cases more complex than your application written on top of them. Suddenly you need to modify code written by total strangers, often either way smarter than you, or worse, quite opposite... and the simplicity of your neat application means nothing in face of complexity of the framework engine.

Re:O'Reilly Posts One Weird Trick Every Programmer

[JustAnotherOldGuy]

Ok, why?

Lots of reasons, but one of the killers for me was that it scatters code all over the place. If you need to make a change you often end up having to screw around with multiple files. Change the model, change the controller, change the view. Lather, rinse, repeat. Need to change the view? Great, you'll have to change the model and the controller more often than not. Same goes for the model and the controller- any change anywhere usually necessitates touching multiple parts of the project over and over again.

Also, as someone else pointed out, it's often needlessly complex for smaller projects or one-off jobs. I just find the whole MVC paradigm to be a pain in the ass from start to finish. If it works for you, great, but it's not my cup of tea.

Re: #1 Don't read O'Reilly books

[Anonymous Coward]

The 1st thing every aspiring programmer in North America should know is - for the fuck sake, leave the fucking programming aside and do something better with your life, something which will allow you to enjoy your life and live it healthy and fully, not bound to a desk 24/7 in the best years you have, for that you have the outsourcing to the slave farms in Asia or the imported slaves.

Stupid and Lazy

[tobiasly]

"Be Stupid and Lazy" sounds a lot like Lary Wall's "Three Great Virtues of a Programmer: Laziness, Impatience, and Hubris" http://wiki.c2.com/?LazinessIm...

Of course, maybe the "Be Stupid and Lazy" author was just being lazy :)

Re:Poop

[__aaclcg7560]

That's a problem when teaching pre-schoolers programming concepts.

Re:Problems with pointers

[__aaclcg7560]

Programmers in school today have problems with pointers because SJW nimwits teach them to believe that "men's room" is a pointer that can be interpreted in two ways

The ordinary prick vs. the overloaded prick. After all these years, you would think the latest version of C++ would have settled this problem.

Good book for getting back into Java...

[__aaclcg7560]

This week I had to install Ant to automate some Python programming tasks. Of course, Ant requires Java. I haven't touched Java since I graduated from community college 10 years with an A.S. degree in computer programming and had to learn all flavors of Java because the CIS department couldn't afford to renew the Microsoft site license for Visual Studio, and, when the site license got renewed, none of the computers could run VS .NET. I really wanted to learn C++ instead of Java, but industry surveys showed that local employers wanted VS C++ and not GNU C++.

Anyway, Ant renewed my interest in Java. Any good O'Reilly book to get back into that language?

Re: Good book for getting back into Java...

[Anonymous Coward]

Why the hell did you have to use Ant of all things to automate some Python programming tasks?! Why didn't you just use Python?!

Re: Good book for getting back into Java...

[__aaclcg7560]

Why the hell did you have to use Ant of all things to automate some Python programming tasks?!

Needed something to automate the generation (Pelican), archiving (zip) and publishing (rsync) of my static websites.

Why didn't you just use Python?!

Python automation tools don't work with Python 3 and/or imposed a file structure that doesn't work with the Pelican static website generator. All Ant required was a build.xml file to do what I wanted it to do. That was faster than creating a Python script to do the same thing.

Re: Good book for getting back into Java...

[Anonymous Coward]

Why the hell did you have to use Ant of all things to automate some Python programming tasks?!

Needed something to automate the generation (Pelican), archiving (zip) and publishing (rsync) of my static websites.

Why didn't you just use Python?!

Python automation tools don't work with Python 3 and/or imposed a file structure that doesn't work with the Pelican static website generator. All Ant required was a build.xml file to do what I wanted it to do. That was faster than creating a Python script to do the same thing.

Use make.

Re: Good book for getting back into Java...

[__aaclcg7560]

Use make.

Make looks too arcane to learn. Ant XML was more straight forward to learn. Not surprise there since I wrote an XML parser in Java for my independent programming project prior to graduation.

Re: Good book for getting back into Java...

[Anonymous Coward]

> Python automation tools don't work

Fixed That For You..

Python automation tools *aren't*. They're an unstable morass of scripting tools to write your own automation suite with, designed to create job security by forcing you to rewrite the tools with *every minor release installed by 'pip install'" without compatibility with any other python compatibilities.

Re:Good book for getting back into Java...

[Anonymous Coward]

best java books are now Android books, that "just so happen" to teach java...

Once you know System.out.println(""), how objects work, and the rest... then I'd suggest Doug's videos on Android & Java. He teaches advanced Java concurrency topics in the domain of Android ( but at least 3/4 are applicable in other domains, and 1/2 in all java)

https://www.youtube.com/channel/UCt-Wvc_ojTzGLpjhruIXYSw/playlists

Literally the person who wrote the POSA (Pattern Oriented Software Architecture) books (vol. 2-5), professor at Vanderbilt University, and someone I've dealt with personally (for disclosure)

Re: Good book for getting back into Java...

[TheRaven64]

Did you really just say that make is arcane, but XML is straightforward?

Re:Good book for getting back into Java...

[Anonymous Coward]

C++ is C++. You can learn the majority of the language using any compiler. Ant runs on Java, but you don't need to learn a single line of Java to run Ant or write Ant scripts. At most there are two types of Java, the open JDK and Sun/ Oracle's JDK. You should never use the special Sun classes so really there's only one flavor of Java. I don't know what you thought you learned. Your school was a really shitty school. You're going to need to do a lot of reading to replace your failed education.

Re: Good book for getting back into Java...

[Anonymous Coward]

LOL, this ^^^

Re: Good book for getting back into Java...

[AmiMoJo]

XML is extremely straightforward and regular. It's just that you end up with a 20:1 ratio of metadata:data.

Make's syntax is correctly described as arcane. Lots of special characters and strings, terse and difficult for people unfamiliar with it to parse. Well, okay, it's not arcane in the literal sense, it's well documented, but the history of the syntax and the way it has been hacked and evolved over the decades is.

Re: Good book for getting back into Java...

[SharpFang]

But you've gotta admit make IS arcane if you want to use it for anything more complex than configure-build-install.

Re: Good book for getting back into Java...

[Anonymous Coward]

Needed something to automate the generation (Pelican), archiving (zip) and publishing (rsync) of my static websites.

Why not just use the fucking built-in Fabric or Make automation? Jesus christ, talk about reinventing the wheel and not bothering to learn your toolset.

Pelican *creates* the makefile for you, all you have to do is type:

'make html' or 'make regenerate' for development;
'make publish' to generate the site with production settings;
'make rsync_upload' to publish over rsync + ssh;

The only thing the makefile doesn't give you out of the box is "archiving" - which is... again... a fucking single command:

tar -czf ${archive_dir}/site-archive-$(date "+%m-%d-%Y-%H.%M.%S").tar.gz ${site_dir}

(adjust ${site_dir} to be whatever directories you're trying to archive. Or, check the whole goddamned thing into a git repo, and just commit & push.) That command could *trivially* be added to the auto-generated Makefile, or into a standalone makefile as a single target.

You don't need python or ant to automate this shit with pelican. And yes, both the makefile & the fabric automation work under python3. Go read your manual, specifically the automation section: http://docs.getpelican.com/en/...

Re: Good book for getting back into Java...

[__aaclcg7560]

Why not just use the fucking built-in Fabric or Make automation?

Fabric is compatible with Python 2: "Fabric is a Python (2.5-2.7) library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks."

http://www.fabfile.org/

Make will run under Cygwin but not under PowerShell on Windows.

Jesus christ, talk about reinventing the wheel and not bothering to learn your toolset.

It took 30 minutes to create the Ant build.xml file and five minutes to modify the build.properites file for a half dozen websites. That's not reinventing the wheel. It's using the right tool for the job.

Re: Good book for getting back into Java...

[__aaclcg7560]

Did you really just say that make is arcane, but XML is straightforward?

Yes. I wrote an XML parser (reader) for a college class. Any idiot can write XML tags. Parsing XML tags without the assistance of any XML APIs made for a challenging project. The Ant build.xml file isn't that complicated to learn.

Re:Good book for getting back into Java...

[__aaclcg7560]

C++ is C++. You can learn the majority of the language using any compiler.

True. If the dean had his way, he would have taught C/C++ using Linux. But the administration said no because the surveys of local Silicon Valley companies reported that they wanted graduates who knew Visual Studio C++ — or Java.

You should never use the special Sun classes so really there's only one flavor of Java.

"All flavors of Java" is my joke regarding the IDEs available for Sun Java after the dot com bust: Notepad, Eclipse or Net Beans.

I don't know what you thought you learned.

Programming. Not software development, software design or computer science. Six years as a professional video game tester and five years of programming classes had made me an effective troubleshooter in my IT support career.

Your school was a really shitty school.

Community colleges are responsive to the needs of the community. I went back to school at a shitty time after the dot com bust. When I started in 2002, I couldn't get classes because they were too many students. When I graduated in 2007, I couldn't get classes because they weren't enough students. Healthcare became the new money major. Everyone and their grandparents had to enroll in healthcare.

You're going to need to do a lot of reading to replace your failed education.

I'm working my way through an old compiler textbook, translating Borland C into modern C and learning Pascal at the same time.

Re:Good book for getting back into Java...

[Anonymous Coward]

I like O'Reilly's Learning Java by Patrick Niemeyer. The principal author is old Sun hand was around Java back when it was still called Oak, so he knew about the rationale for all the design decisions, and it shows.

The Swing/desktop stuff (probably written by Niemeyer's co-author) makes up the last 35-40 percent of the book. That's good, because Swing isn't relevant to many developers these days.

I have the third edition which came out in 2005 or so. It covers Java 1.5 ("Tiger") which includes generics. There's a newer edition of the book, but I figure I need another book anyway to learn Java 8.

I also have Core Java from Horstmann, but don't like it as much.

Re: Good book for getting back into Java...

[Anonymous Coward]

Fabric is compatible with Python 2:

pip3 install fabric3

Fabric3 is a drop-in replacement for fabric which is compatible with pythons >= 2.7.

Make will run under Cygwin but not under PowerShell on Windows.

So use Fabric3 with python3. Or fabric with python 2, which is still perfectly well supported. If you have the ability to blast the JDK and ANT out onto your servers, you have the ability to install a supported python 2 version.

It took 30 minutes to create the Ant build.xml file and five minutes to modify the build.properites file for a half dozen websites. That's not reinventing the wheel. It's using the right tool for the job.

No, that's wrapping a utility in your own custom scripting, which means that you have to support it yourself, and you're saddled with the constant ongoing maintenance and upgrade cycle. And that's called "Not Invented Here" syndrome. It's a thing. Look it up.

Re: Good book for getting back into Java...

[__aaclcg7560]

Fabric3 is a drop-in replacement for fabric which is compatible with pythons >= 2.7.

Fabric3 is a Java container.

http://fabric3.org/

If you have the ability to blast the JDK and ANT out onto your servers, you have the ability to install a supported python 2 version.

The only thing I blast to my servers are static web files. I have Python 3, Java and Ant installed on my laptop.

No, that's wrapping a utility in your own custom scripting, which means that you have to support it yourself, and you're saddled with the constant ongoing maintenance and upgrade cycle.

Which is what I'm already doing for my websites.

Re:Good book for getting back into Java...

[Anonymous Coward]

If you need a book to get "back into" a language, you're not really a programmer. Community college, huh?

Re:Good book for getting back into Java...

[__aaclcg7560]

If you need a book to get "back into" a language, you're not really a programmer.

Java changed quite a bit since I last used the language 10+ years ago. Real programmers aren't afraid to ask for help or look up reference materials.

Community college, huh?

Paid for with a $3,000 tax credit that George W. signed into law after 9/11.

Re: Good book for getting back into Java...

[Anonymous Coward]

I started with this:

https://www.freebsd.org/doc/en/books/pmake/

No, it's not GNU make. Yes, it has differences -- mostly the special variable names that are actually legible.

Re: Good book for getting back into Java...

[Anonymous Coward]

Fabric3 is a Java container.

No, you dumb twat, the fabric3 under discussion is a python module, as the 'pip3 install fabric3' command would have suggested to you, if you weren't a half-wit with no knowledge of python, and no legitimate reason to be near the business end of a computer.

The only thing I blast to my servers are static web files. I have Python 3, Java and Ant installed on my laptop.

Even easier - install python 2.7 as well, learn to virtualenv to keep your installation repeatable & uncluttered, and use the pelican module out of the box with fabric. You've INVENTED a need for a new tool by specifying requirements that aren't requirements. You didn't HAVE to go install a JDK and Ant, you are not constrained by the version of python already installed on your laptop. Or do yourself one better, vagrant up a centos-based host, and use a proper fucking development machine instead of some half-assed "I'm an IT guy who loves to talk about the right tool for the job, but can't apparently discern what the right tool for a job is, or that the tools I'm already using offer the exact functionality I say I need out of the box."

Which is what I'm already doing for my websites.

Websites = content you publish. All the other shit that you have to download, write, and manage to that end is tooling that serves the goal of publishing your content. If publishing your content can be achieved in these two ways:
1) download a few existing packages, then combine them to use their native functionality to publish your website;
2) download the same few existing packages, then wrap them in a bunch of custom scripting from 2 other tools to replace the native functionality already available to you without the wrapper to publish your website;

Then the proper choice is *always* #1. ALWAYS. Writing a bunch of one-off support scripts that are required to achieve your goal is taking focus away from the goal, and making your environment more complex, harder to debug, and harder to maintain. The net result is that you will spend MORE time on maintenance and dicking around with tools, and LESS time on publishing your websites.

Again - "Not Invented Here syndrome". It's a thing. Look it up.

Re: Good book for getting back into Java...

[__aaclcg7560]

No, you dumb twat, the fabric3 under discussion is a python [python.org] module [github.com], as the 'pip3 install fabric3' command would have suggested to you, if you weren't a half-wit with no knowledge of python, and no legitimate reason to be near the business end of a computer.

I find your lack of sense of humor disturbing. Turn in your geek creds. Don't let the door hit your ass on the way out.

You've INVENTED a need for a new tool by specifying requirements that aren't requirements.

I didn't invent anything. I write Python 3 code. My codebase is Python 3. I haven't done anything Python 2 coding in over two years. Since this is MY LAPTOP and MY WEBSITES, it's MY REQUIREMENTS that have to be satisfied.

Writing a bunch of one-off support scripts that are required to achieve your goal is taking focus away from the goal, and making your environment more complex, harder to debug, and harder to maintain.

I wrote the Ant build.xml in 30 minutes. It took five minutes to modify the build.properties files for a half-dozen different websites. If I type ant, my website is generated. If I type ant all, my website is generated, archived and published. Ant works in Powershell and Cygwin without having to write a separate script to accommodate different path configurations ("C:\websites\" vs. "/cygwin/c/websites").

Again - "Not Invented Here syndrome". It's a thing. Look it up.

I'm not a purist. I'll use whatever tool that will get the job done.

Re: Good book for getting back into Java...

[__aaclcg7560]

No, you dumb twat, the fabric3 under discussion is a python [python.org] module [github.com], as the 'pip3 install fabric3' command would have suggested to you, if you weren't a half-wit with no knowledge of python, and no legitimate reason to be near the business end of a computer.

It took 45 minutes to get Fabric3 working under PowerShell but not Cygwin, the fab file generated by Pelican for a single website has 60+ more lines of code than the Ant build.xml file I wrote from scratch, and the configuration variables are all wrong. I'm not impressed.

Re: Good book for getting back into Java...

[unrtst]

Makes syntax isn't arcane. I don't mind the special characters at all (but I prefer to work with perl, so you can safely ignore me from the norm).

What is arcane is its inability to work with filenames that contain spaces, and it's incomplete toolset (why should you have to shell out for so many common tasks). It works very much like many unix tools, but that means it's all text, lists are just space separated text, and there is no real list/object/dictionary/etc.

I still really enjoy working with it, but I'm pretty sure some of that enjoyment comes from the challenge of it.

Re: Good book for getting back into Java...

[Anonymous Coward]

I write Python 3 code. My codebase is Python 3.

What codebase? Pelican is third party code. That's like saying you'll only run perl code, because you write perl code. If you can run it out of the box with an install of python 2.7 (which is fully supported, and can be trivially installed alongside python 3), and instead you go off and reinvent a bunch of shit pointlessly, well - welcome to your dead-end career maintaining the same shit you cobbled together 10 years ago.

Also, given your commentary, it's clear that you know fuck-all about virtualenvs in Python - which suggests that your "Python 3 codebase" is both small, and uninteresting, in the first place.

I'm not a purist. I'll use whatever tool that will get the job done.

Unless that tool is not Python 3, and Ant, apparently. This is exactly the fucking point: the tools to make this work already exist, and are trivially loaded on your dev system. Yet you went and reinvented functionality that already exists because of some bizarre notion of ideological purity. You ARE, demonstrably, a purist, and you WILL, demonstrably, refuse to use existing tools that will get the job done.

Re: Good book for getting back into Java...

[Anonymous Coward]

XML is extremely straightforward and regular.

Says someone who has never had to deal with XML namespaces, schema definitions, document type definitions, XSLTs, XPath, XQuery, and the list goes on. Sure a build.xml seems simple, but the broad claim that XML is extremely straightforward is dumb.

Re: Good book for getting back into Java...

[__aaclcg7560]

What codebase?

My codebase — the only one that matters.

[...] welcome to your dead-end career maintaining the same shit you cobbled together 10 years ago.

One of my websites is 20 years old.

This is exactly the fucking point: the tools to make this work already exist, and are trivially loaded on your dev system.

Ant took me 35 minutes to write once and get working on a half-dozen websites. Fabric3 (Python) took 45 minutes to set up, didn't work under Cygwin, took an extra 60 lines of code to do what I did in 30 lines of XML, and the configuration variables for ONE SYSTEM was messed up. If I was to use Fabric, I would have to reinvent Ant.

Re: Good book for getting back into Java...

[Anonymous Coward]

My codebase — the only one that matters.

Your web site codebase is not written in python3, if you're using Pelican - it's written in fucking Markdown. One more reason we can tell you're not a programmer - you seem to think that every piece of code you write must be in a single language, and is all part of "my codebase."

One of my websites is 20 years old.

Great, you can spend the next 20 years maintaining your stupid codebase and never advancing or learning anything new.

Ant took me 35 minutes to write once and get working on a half-dozen websites.

And installing python2, making a virtualenv, installing pelican & beginning to publish using the native fabric functionality shouldn't take somebody competent and familiar with python more than the time it requires for their computer to process the commands.

Re: Good book for getting back into Java...

[__aaclcg7560]

Your web site codebase is not written in python3, if you're using Pelican - it's written in fucking Markdown.

Some of the website content is written in Markdown. The rest are in Python data structures that are manipulated by other Python scripts and Jinja2 in the templates..

Great, you can spend the next 20 years maintaining your stupid codebase and never advancing or learning anything new.

Let's plot the evolution of my oldest website: Basic HTML (1997-2002) -> LAMP (2002-2007) -> Joomla! (2008-2011) -> Wordpress (20011-2016) -> Pelican (2016-Present).

And installing python2, making a virtualenv, installing pelican & beginning to publish using the native fabric functionality shouldn't take somebody competent and familiar with python more than the time it requires for their computer to process the commands.

I'm using Python 3 exclusively on my systems. You should get with the program and make the transition.

https://wiki.python.org/moin/Python2orPython3

Re: Good book for getting back into Java...

[Anonymous Coward]

I'm using Python 3 exclusively on my systems.

So you admit that your claims of "best tool for the job" are bullshit. Thanks for playing, son.

Re: Good book for getting back into Java...

[__aaclcg7560]

So you admit that your claims of "best tool for the job" are bullshit. Thanks for playing, son.

You don't like like Java and Python 3 because they're not Python 2. Hmm... That's says lot, grandpa.

O'Reilly: Poor management, poor editing

[Anonymous Coward]

At a conference, I checked a lot of O'Reilly books. I found sloppy editing on every page of every book I opened.

Re:O'Reilly: Poor management, poor editing

[__aaclcg7560]

Not surprising. An editor told me it wasn't his job to edit the stories that appear in his magazine if the author didn't do a thorough job in editing before submission. An editor no longer edits anymore. That was during the transition from snail mail submissions to emails submissions.

Re:O'Reilly: Poor management, poor editing

[Anonymous Coward]

Back when slashdot was still good (inb4 slashdot was never good) like 15-20 years ago (damn where did my life go) oreilly books were actually pretty good and usually the first publisher you turned to when browsing brick and mortar barnes and noble. these days the oreilly animals books tend to be pretty sucky, and still don't have syntax highlighting in the code (many other competitors do) it's like wow, they sure turned to shit, sad! star wars getting raped by hollywood doesn't bother me, but o'reilly sucking ass is a real assault against my nostalgia.

Re:O'Reilly: Poor management, poor editing

[Anonymous Coward]

Dude, I hate to break it to you, but Star Wars has always been pure Hollywood.

Re:O'Reilly: Poor management, poor editing

[TheRaven64]

O'Reilly books have always been bad, but they were also cheap. You could get an O'Reilly book for under half the cost of one from a competing publisher, so you'd overlook the poor writing and poor editing (and there were a few gems that were fairly well written). The change is that the basis for comparison is not expensive books from another publisher, it's free blog articles online. O'Reilly books look really expensive compared to free, and the price difference isn't reflected in the quality.

Deliberate Practice

[Bengie]

Do Lots of Deliberate Practice ... "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts."

The quote about deliberate practice is taken out of context.
1) It is said it typically takes 10,000 of deliberate practice to become "elite", but it can take as few as 100 hours for those "naturally" good at something
2) This mostly applies to professions where practice matters, like playing an instrument. As a profession becomes less about muscle memory and more about thinking, practice becomes less useful.

Becoming an elite in a purely intellectual profession can require virtually zero practice. Some people are able to learn by thinking. They can reason through to the conclusion without having to actually practice/experience. Of course nothing is purely intellectual. Even with programming, we have to deal with other humans and need to deal with the fact that we are also human and can make mistakes. You must learn to write clear and defensive code, and be able to communicate with others.

Rule of thumb, don't write any code until you understand the problem and have thought of a good solution. If you were wrong at any point, figure out what was wrong with your reasoning that lead to the mistake and don't make that same logical mistake again. It really comes down to having strong fluid intelligence. This is how someone realizes what they don't know and if what they do know will work for the situation at hand. If you suffer from Dunning–Kruger effect, have a golden hammer, or don't realize you're doing something wrong, you probably need to exercising your fluid intelligence.

Re:Deliberate Practice

[MrKaos]

Rule of thumb, don't write any code until you understand the problem and have thought of a good solution.

Are you suggesting people think *before* they code. How Dare You._howdareyou_.

Seriously though sometimes I write a prototype knowing I'm going to throw 90% of the code away, I just want to know where the hard problems will be before I invest too much in anything else. Sometimes you end up with a few gem ideas that you can refine.

Re:Deliberate Practice

[Bengie]

You know that you're going to throw away most of the code. Most people don't see a prototype meant as a learning experience, they instead see "working" code. All working code is equal in their mind. Except they don't actually know how it works, it only seemingly works. You can tell they don't know how it works when something finally goes wrong and they can't even guess as to why it's not working.

One of my rules of thumb is "You can't know why your code doesn't work unless you first know how it works.". 80%+ of the time, in the rare case that someone finds a bug in my code, I can typically tell them where the bug is and under which situations it will occur without ever looking at the code or using a debugger. I can many times do the same thing to other's people code for which I have never seen. I can infer much of how their program is designed based on how the characteristics of the bug. I purposefully try to write well-factored code with single-responsibility to make it easy for me to reason about. When I get dragged into helping someone debug their code because they're lost in their own maze.

Many times I've had programmers tell me they think there is a bug in .Net or SQL because their program is not working correctly. They can't even understand their own code, why are they so willing to blame someone else's?

Re:Deliberate Practice

[Anonymous Coward]

> You can't know why your code doesn't work unless you first know how it works.

Actually, I think that holds a lot of people back. Particularly when debugging legacy code where knowing how it works is not all that realistic.
What you actually need to know is how the code SHOULD work. With some error bars for corner-case etc. you haven't considered.
Sometimes you can even get away with just knowing how the code should NOT work to fix a bug.
But admittedly, each of those shortcuts increase the risk of your fix being wrong and breaking more than it fixes. But it can speed up debugging a LOT.

Re:Deliberate Practice

[Bengie]

Sometimes you can even get away with just knowing how the code should NOT work to fix a bug.

I wish I was so lucky. When ever I have to deal with other software engineers, they only define the overly simplistic happy paths. Failure paths? What are those? That really grinds my gears. I always rub their nose in it when I ask them if that is how it should work, only to find out they did not think of that situation. I just tell them it is undefined, so it is not a bug. "Fixing" the situation is now a feature request.

I should refine my statement. "You cannot know how your code does not work until you know how it is supposed to work, and you cannot know how your code is supposed to work until you know how it should not work." I work with very complex multi-threaded code. Every bug that I have not been able to explain has been a result of a bug in the framework or library that I used. I make sure my code has well defined failure paths and guaranteed state transitions handled by single points of responsibility.

Particularly when debugging legacy code where knowing how it works is not all that realistic.

I actually get pulled into helping people debug their code when I don't even have access to the code. I find the quickest way is to just keep asking "what all is responsible for handling this and how are they meant to work". Even when working at an abstract level, I can help them find the issue quickly with the above approach. And it always makes for a good time to slip in "imaging how much easier this would be if you only had to look in one place". SOLID is your friend.

Some times I don't even get the advantage of someone to ask, seeing the code, or knowing the architecture. Everything that I know is just what the customer reports and I have to infer the rest and make lots of educated guesses. And I still mange to figure out the problem faster than the ones who wrote it. But I've always had a strong intuition when it comes to computers. My co-worker is very intelligent, but he has little intuition. He has a math background and can quickly implement nearly any algorithm or protocol by reading an RFC. He needs empirical data. The problem is a lot of the hard issues we deal with, you only get to see the symptoms, which means all of your empirical data is not about the cause, but the effects created. Many times if you read too far into the data, it will send you in the wrong direction.

I always strive to have a theory why something works the way it does. If my theory does not match, I try to create predictions with my theory and see if the are true. My co-worker doesn't really have a theory, he just has a bunch of data and reads it too literally. The thing is, I cannot argue against his logic, he has flawless logic, what I argue against are the hidden variables that cannot be directly measured. My theories predict these and make clean predictions. He has learned to humor me with my thoughts.

A simple example is perhaps he looks at the memory profiler and sees some objects getting promoted to Gen2 and causing lots of GC. Then I argue that in theory, those objects should be used momentarily and the root issue is something is blocking the release of those objects. Look around, and see a stack variable that references those objects well past when they're needed, but the resulting work caused by those objects is taking some time, keeping the stack reference in scope. Just null the stack reference to the objects after they're needed, and the problem goes away.

Re:Problems with pointers

[Anonymous Coward]

Overloaded pointers are a problem. They tend to be truncated and therefore quite useless.

Picking one at random

[russotto]

The Professional Programmer

What is a professional programmer?

A professional programmer is someone who gets paid to do the job of programming.

Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.

Sorry, bud, but professionals take responsibility for what they're paid to take responsibility for; no more and no less. And push responsibility off when appropriate too, like when their boss commits them to a schedule they can't make without compromising workmanship.

If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way?

Hell, yeah, they do. What do you think a resident is? Maybe the author is confused because after residency, many doctors are owners of their own practice, at which point they are not just professionals but business owners. Me, I draw a salary. If my training is going to benefit The Company, it's on The Company to provide it.

Professionals take responsibility for the code they write. They do not release code unless they know it works.

Again with the confusion between a professional and someone with independent authority. My code goes out when the boss says it goes out, ready or not.

Professionals are team players. They take responsibility for the output of the whole team, not just their own work.

Obviously not familiar with life in a corporation. Managers and leads take responsibility for the output of the whole team, when that output is good. When things are fucked up, THEN the programmers get the responsibility. Shit flows downhill, credit is taken upward.

Professionals do not tolerate big bug lists.

Professionals fix those bugs, and only those bugs, they're being paid to fix. The rest can sit in the issue tracker until doomsday. Ain't no point in getting the boss riled up over spending time fixing a minor floating point division error when you're supposed to be working on the shiny new feature.

Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, ever rush.

A professional rushes when being paid to rush. A professional keeps the code clean when practical under the constraints of the job. If that means we're getting the code out on time only with a bunch of copypasta and a goto or two, that's how it's going.

Professionals get paid. If they have a rare combination of independent authority and a client with respect for them, maybe they can have other principles too. Otherwise, they write the code which gets them paid.

Re:Picking one at random

[MrKaos]

This comment is exactly what a professional programmer would say.

Pay for my own training on some arcane system where there is no return on my investment, "If you pay for it" - That is what a professional programmer would say. Personal responsibility for the things I'm responsible for. Responsibility without leadership is another term for 'punching bag'.

So, fuckin A, mod parent up and up for such a professional comment.

Re:Picking one at random

[Anonymous Coward]

Sorry, bud, but professionals take responsibility for what they're paid to take responsibility for; no more and no less

And where can I find a programming job that isn't being paid to take responsibility for mistakes and workmanship? If you're not being paid to take responsibility for a commitment... then it isn't really much of a commitment anyway. At least you're not paid to take responsibility for your career, but you have self-interest in thinking about the long term. I'm not sure what your beef is since what you said seems more or less orthogonal.

Re:Picking one at random

[nasch]

Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way?

My wife is a certified nurse-midwife (same level as nurse practitioner, basically a step below MD) and her employer pays for her continuing medical education. Maybe he should stick to talking about programming and programmers.

Re:Picking one at random

[mark-t]

You may be a professional, but if I may be frank on the matter, you come across as having the attitude and work ethic of a rank amateur. I've sat in at interviews with would-be colleagues who demonstrated similar attitudes, and thankfully none of them ever got hired on. I have also had the misfortune of working with a few that I did not sit in on the interview with, and in my experience, they move on quickly, rarely sticking around with any one company for more than about a year or so.

So yes.... you might get paid, but if you don't have enough of a passion to do what you get paid for to want to do the best job that you *possibly* can, regardless of what you actually might get paid to do it, then odds are going to be that you will be passed up for promotions, or let go when the economy downturns while people with more positive attitudes who genuinely cared about their work stay on, or sit back watching others move upwards along the professional ladder, leaving you trailing far behind.

Professionalism isn't just about being paid to do a job, in addittion to having the raw skill to do the job, it's also about having an attitude towards that job that merits other people *wanting* to pay you to do that job, and that generally entails having a personal investment in doing your own personal best, regardless of the size of the paycheque. After all, if your employer doesn't really *want* to pay you to do it, then at best any money you are making right now is only the result of inertia, and not because of any merits that you may have to convince them that you are *actually* worth what you make. There are no skills that you have that another cannot supply, so in the end the only real thing that you can control that will set you apart from other people and make *YOU* the best person for a job is in your attitude.

Which I am afraid, seems to need some adjustment. Good luck to you.

Re:Picking one at random

[Anonymous Coward]

Sorry, bud, but professionals take responsibility for what they're paid to take responsibility for; no more and no less

And where can I find a programming job that isn't being paid to take responsibility for mistakes and workmanship?

How about you tell us which other non-programming job that DOES take responsibility for mistakes and workmanship?

How did the Business Analyst take responsibility when the requirements change every week?

How did the PM take responsibility when he accepted death march schedule? What's his "workmanship" in a death march schedule?

How did management take responsibility when forcing programming teams on death march projects?

What's the responsibility and workmanship of CEOs who run the company to the ground and then take a golden parachute to another company?

Why did people expect programmers to be foolish enough to buy into this kool-aid about "responsibility"?

Re:Picking one at random

[Anonymous Coward]

regardless of what you actually might get paid to do it

So what you're actually saying is you only want to work with people that don't mind being underpaid and overworked. You expect your colleagues to stay back after hours for free to bring the quality of their (working) code up to your standard because your shitty company doesn't allow enough time in the schedule to reach that expected quality.

There are no skills that you have that another cannot supply, so in the end the only real thing that you can control that will set you apart from other people and make *YOU* the best person for a job is in your attitude

Oh my God you're an MBA not a coder. Now I get it. Your company isn't doing anything vaguely interesting or innovative. You're talking about monkeys for the grinder.
Good luck to you sir.

Re:Picking one at random

[ath1901]

I sort of agree but I think you're being a bit too defensive. It is the job of the professional to explain the importance of clean code, fixing bugs etc to your boss. After you, as a technical specialist, has explained the importance of doing things the right way, it is up to your boss to make the business decision of playing safe or taking a risk. Often, risks are not just in the code. If the release is delayed (again), the customer may loose confidence (again) and leave. It is the job of the boss to weigh risks against each other. (Yes, I am well aware many many bosses do not understand what bossing is about and are tragically unable to understand the concept of risk).

I agree the initial list is idealistic bullshit but it is the responsibility of a professional to explain the importance of best practices anyway. If you'd add a "try" to every sentence, the list would be much better. See:

Professionals try to take responsibility for the code they write. They try not to release code unless they have good reason to believe it works.

Professionals try to avoid big bug lists.

If you are a professional, then you try to be responsible for your own career. You are sorta responsible for reading and learning. You are maybe not responsible for staying up-to-date with the industry and the technology. Not enough programmers understand that it is their employer's job to train them. Sorry, this is just dead zombies. Doctors behave that way

No, sorry. That didn't work out. It is still pretty dumb. Big bug lists are fine if the bugs are non-essential. You should work on what is important to your users; if they don't mind bugs in the "About" window, don't fix them. Clean and bug free code is an ideal that we strive toward but it is an ideal and not reality. If you've ever had to fix bugs or add functionality to a decade old bowl of spaghetti bolognese, it won't be clean, you won't be proud of your work and you know it will fail again.

Re:Picking one at random

[ath1901]

You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way?

I just can't stop thinking about the stupidity of this.

Doctor: Hey, patient, would you like to try some new meds I read about on the internet yesterday while my kids were screaming? I haven't tried them or read any scientific studies and I am unsure about the use-case compared to existing drugs but they are very popular in some facebook groups.

Navy Officer: Hey, we're getting a new aircraft carrier next year so I expect all of you to go home and read up on it and start practicing at home. We'll call you when there is a war and your skills are needed. You'd better be self-trained experts by then!

University head: What's all this "research" I keep hearing about? Take some responsibility for your own careers and stay up to date in your spare time! Now, go back to work. We need more folded napkins!
     

Re:Picking one at random

[russotto]

So yes.... you might get paid, but if you don't have enough of a passion to do what you get paid for

It is passion that is the mark of the amateur; the word is derived from the Latin for "love", after all.

To a professional, passion is dangerous, it leads to doing things that aren't remunerated.

then odds are going to be that you will be passed up for promotions

Ah, but promotions in this profession are a simple and spare thing. You work a few jobs, eventually you start calling yourself "Senior". After that, there's nowhere for a programmer to go and remain a programmer. You want to go beyond that, and you have to become a manager, or a lead, or an architect (God forbid!). Or you can go into business for yourself as a consultant, where you will have to be even more mercenary.

Re:Picking one at random

[SharpFang]

Whoa, so much hot air you could fly a blimp across the Pacific on it.

Professionalism isn't about staying at a job that doesn't pay your worth.

And with your attitude regarding requirements and salaries, you only qualify as a professional con artist.

Re:Picking one at random

[Anonymous Coward]

So yes.... you might get paid, but if you don't have enough of a passion to do what you get paid for to want to do the best job that you *possibly* can, regardless of what you actually might get paid to do it

I am not a coder, but guess this is roughly similar in most lines of technical (and probably other) work: there is a limited amount of time and an apparent unlimited amount of work to do. Employees, or their boss, need to prioritise, and this may mean doing things in another way than you would for a hobby project. If, under thse conditions, one would want to polish software (or any other result) like one would for a hobby project, that would lead to significant unpaid overtime.

Why would anyone, except inexperienced young employees, do that? If the company wanted me to work more hours than in my contract, they should have given me a different contract. Or give a bonus or whatever. To company is saving money by not hiring more staff, but somehow the employee should pay for this by working unpaid hours to comply with your "passion". I have passion for other things besides my work too.

Re:Picking one at random

[mark-t]

There's a funny thing about money.... beyond a certain point past once mere survival ceases to be an issue (and if an employer is treating employees fairly and paying them what they should be worth, then this is most definitely an achievable thing, at least in this industry), you actually stop caring about how much more you can get. You get to have the luxury of caring about how good the work you do is *beyond* what that might mean to you financially because in the end, it isn't money that is going to give your life any sense of satisfaction with yourself or the believe that you have a life that is in any way worth living, it is your own confidence and joy that you derive from doing whatever it is that you do.

My employer does not place any overtime hour demands upon me that he does not fairly compensate me for in some way, but that does not mean I will not work overtime without renumeration on some occasions without being asked to get some tasks complete.... Truthfully, I do this more for my own benefit than the company's, because by putting in that extra time on occasion, I am able to leave work behind when I return home, and be able to fully enjoy the time with my wife and family instead of allowing a possibly nagging concern to eat at me over the night or the weekend about whether a particular task will be getting done on time.

Re:Picking one at random

[Anonymous Coward]

> Why did people expect programmers to be foolish enough to buy into this kool-aid about "responsibility"?

Indeed. If manglement is about to make a disastrous decision, it is my professional responsibility to inform them that said decision is disastrous for X specific reasons, and to provide them with alternative options. If they persist, I go along. Because I'm not being paid to have responsibility for the outcome: that is literally their job, and the reason why they are paid more than me. And I certainly won't be working overtime for free to fix the inevitable fallout. This isn't up for debate; it says so in black-and-white on my contract.

Same as this ridiculous notion that "real" programmers ought to code stuff day and night in their free time as well. If you happen to have a life outside code, you apparently don't count as a "real" programmer any more. But asking a GP if he spends his free time doing house calls "for fun" is considered weird; asking your manager if he uses the same management style at home is apparently downright insulting. Who knew, right?

Re:Picking one at random

[__aaclcg7560]

If you happen to have a life outside code, you apparently don't count as a "real" programmer any more.

I know a couple of guys who graduated as computer engineers from the university, got good jobs and never bother to stay current with technology on their own time. About seven years later, they both got laid off during the dot com bust, took a six month vacation while drawing unemployment benefits, and discovered that their job skills were obsolete. They could have bought a book, went back to school or enrolled in a boot camp. They didn't. AFAIK, they're still working as drug store clerks.

Re:Picking one at random

[mark-t]

Why would anyone, except inexperienced young employees, do that?

Because they care about doing the best work that they can... they want the quality of their work to be exemplary of the very best they can do, so they can take personal pride and satisfaction in how they did the job. I am over 50 years old, and have been in this industry professionally now for roughly half of my life. I don't think I'm particularly inexperienced, and the only people who ever call me young these days are those who are my parents age.

Re:Picking one at random

[Cesare Ferrari]

Agreed. The field is just too large for people to have *any* chance of keeping a useful handle on what is going on. You are going to have to specialise. The trick I think is to know what you don't know, not to keep up with everything. I was recently asked by a potential client if I could produce a mobile phone app for them - 'no chance, i'm not competent at that' was my reply. I pointed them at someone who specialises in this work. Knowing what you don't know (and who does!) is a much more useful skill than attempting to keep up with everything...

Re:Picking one at random

[avandesande]

If manglement is about to make a disastrous decision, it is my professional responsibility to inform them that said decision is disastrous

Learned a long time ago to never give advice unless asked

Re:Picking one at random

[Anonymous Coward]

Technical knowledge has a half life of about 3-5 years. Training is only worthwhile if you plan on immediately using your new founded knowledge. I try not to remember too much. I save my brain for thinking, not memorizing. There is actually an inverse correlation with knowledge and abstract reasoning. The more you know, the more your use your memory and the less you use your reasoning. After your teenage years, your abstract reasoning starts to drop off and tanks after 30, assuming you focus on learning knowledge. Those to focus on learning understanding maintain abstract reasoning for much longer and have a greater peak.

Leave the knowledge for search engines.

Re:Picking one at random

[Bengie]

I wouldn't say you have to specialize. It would just mean you need to spend more of your time researching. In general, I find I can catch up to almost any specialist within a month, but that's a month of no production, just learning. That is a lot of down time. On the flip side, most projects that we have take 6 months to a year, and spending 1 month of it researching to catch up to what a specialist spent a life-time specializing is probably acceptable.

It really comes down to the size of your project. If it's really small and needs to be done quickly (less than several months) and well, go with a specialist.

165 opinions, many of which are wrong

[Pseudonym]

I fear for our business when this is considered the best advice we can come up with.

BTW, I have a good title for my thing that every programmer should know: "Most things aren't objects."

Re:165 opinions, many of which are wrong

[Pseudonym]

Haha, I got downvoted by a Python programmer.

Personal responsibility? Why not start at the top?

[Anonymous Coward]

I just f*** love it when the lowly programmers were asked to take "personal responsibility" when everyone else who earned more and have more authority, such as managers, wouldn't.

Where's the guy taking "personal responsibility" for the requirements document, which changes weekly/daily?

Where's the manager taking "personal responsibility" when the project have to keep going on the original schedule even when short staffed?

Where's the PM taking "personal responsibility" when unreasonable death march schedule was accepted?

So when sh*t hits the fan, the *programmer* should take "personal responsibility"? You think we were fools?

Learning "new" skills

[Anonymous Coward]

Oh let me guess during your career you or someone else is likely to discover some "new" algorithm nobody else thought of previously.

Or I know general purpose programming language selection results in better software. This is why most software currently worth using is *STILL* written in C/C++.

I routinely deal with idiots who end up believing x, y and z on purely dogmatic grounds unable to justify their positions separate from bandwagon fallacy. They can only parrot accumulations of things they "know" because someone somewhere said so.

The industry generally is full of such lemmings who care about careers and fitting in over actual results. They think they are smart because someone else gave them all the answers.

Number 166 (or actually 165)

[PPH]

Start lists with an index of zero.

Re:Number 166 (or actually 165)

[meta-monkey]

I would say "start lists with the index that's the convention for your programming language." And the only language I know of off the top of my head that uses a starting index of 1 is Visual Basic, and if you're using VB you should probably just kill yourself.

Re:Number 166 (or actually 165)

[tepples]

Lua also conventionally uses 1 as the first index.

Separate Data from interface

[fermion]

I would think that the first thing a modern software develop should know is to decouple interface and logic and data. This is nothing new.

Composite/Structured Design was published way back in the late 1970' and detailed how rules should be in one place only as well as touching on the interfaces to access data and rules. Apple used the MVC structure to separate data from the viewer and methods. OO programming made this much easier to do. Computers are so fast any penalty, in most cases, is irrelevant.

My suspicion is that most software people now simply are connecting widgets to interfaces, and there is no actual knowledge of development or process. this is fine because the frameworks we have are so sophisticated that we can pay people to solve problems rather than figure out arcane error messages on why the code won't compile.

COROUTINES

[Anonymous Coward]

If you don't learn what they are and what languages offer them, you won't be an effective concurrency programmer in this century and A.I. will own your job.

Cargo Cult Metrics without science

[waveclaw]

The Road to Performance Is Littered with Dirty Code Bombs

Unexpected encounters with dirty code will make it very difficult to make a sane prediction.

Dirty code is defined as ' overly complex or highly coupled.' As a programer you are expected to deliver X number of features by Y date. Unless one of those features is 'simple and loosely coupled code' what does that have to do with predicting anything? For performance you don't predict. Experiments are the only thing you have that work: test and change and re-test and un-change and re-test, endlessly. Anything else is voodoo programming, not to insult the pracitioners of Santaria, Vodou or Hoodoo.

How about predicting the schedule? I recall that Steve McConnell once joked that to get better at estimating we need to get better at estimating. (This may have been someone else.) Greg Wilson showed we can do this in programming, and Computer Science in general. We only have to do scientific experimentation with various methods. We throw away what doesn't work (instead of writing pulpy business books to bilk people out of money.) But you'll still have to run a lot of tests to do that, too.

It is not uncommon to see "quick" refactorings eventually taking several months to complete. In these instances, the damage to the credibility and political capital of the responsible team will range from severe to terminal. If only we had a tool to help us identify and measure this risk.

It is my opinion that any refactoring that cannot be done by an automatic program isn't refactoring. The original definition of refactoring is just 'factoring' or re-organizing the code. It is not a re-writing as in an 'several months' effort.

Misuse of a sexy, trendy name from the 90s does not change this. All re-writing suffers the risk of second-system syndrome and not in the throw-one-away sense of prototyping. Do you have a button to press in your IDE to make the change? Do you have in mind a short sed statement, simple awk program, EMACS macros or a on-hand shell scriptlet to do the transformation? If not then you cannot get away from re-thinking the problem. This will require re-design of the solution and re-implementation of the feature. Each of these carries time risk at least as high as the original work.

What if the problem is overly complex or highly coupled? The code may merely be an expression of this. In this case only a paradigm or perspective change by the customer, developer or user can untangle the problem. The computer cannot help you do anything but automate making a mess if the problem is a mess. Changing perspective is often an unbound-in-time problem for human beings. Good luck with estimating completion dates for that.

In fact, we have many ways of measuring and controlling the degree and depth of coupling and complexity of our code. Software metrics can be used to count the occurrences of specific features in our code. The values of these counts do correlate with code quality.

In fact, Greg Wilson showed in his presentation that almost every metric on the market when analyzed showed no better and usually equal predictive power as simple counts of Lines of Code.

The situation in programming is almost as if more code equals more bugs while less code equals less bugs.

This seems obvious and

Re:Cargo Cult Metrics without science

[Bengie]

For performance you don't predict. Experiments are the only thing you have that work

In my experience, I am better at predicting performance than synthetic tests. In many cases, intuition out-ranks empirical evidence because some things are impossible to directly measure, only theory works.

Re:Cargo Cult Metrics without science

[Anonymous Coward]

In complex systems, the act of measuring can change the results.

Production server

[nasch]

Under no circumstances — ever, at all — should a developer have access to a production server.

I'm one of two developers on a five person team. The other people are: CEO/sales, marketing/customer support, and QA. If I didn't manage the production server, there would be no releases. Perhaps this would be more accurate:

Under no circumstances — that I've personally experienced — should a developer have access to a production server.

Re:Production server

[Dog-Cow]

No. Just because you're doing it wrong doesn't mean the advice is invalid. Now, just because you're doing it wrong doesn't mean that you can do it right. I assume there's a financial reason for your setup. But you're still wrong.

Re: Production server

[Anonymous Coward]

Enough with the attacks, AmiMoJo.

Re:Production server

[Anonymous Coward]

No. The real statement should be no programmer should ever develop on a production server. Changes should happen on the development environment and moved to production. That of course requires discipline but that isn't that hard, us nerds can be real sticklers for the rules. Now if a change that passed in development breaks once it reaches production, you then can decide is it easier to rollback or patch production. Either way, once the fire is out you try and figure out why your tests do not model the real world and improve.

Re:Production server

[coofercat]

The real advice is that "while working in the role of Developer, do not have access to the prod servers". If you additionally have the role of "sysadmin" from time to time, then so be it, but don't abuse your development power, nor your sysadmin power.

In my experience of big companies, small companies and a few in between this really does work best. People talk of 'creating high walls' and whatnot, but by forcing devs to mould their output into something system-friendly results in a far superior product and far less maintenance overhead. It appears to take longer to get things into production, hence the 'high walls' comments, but the alternative is almost always worse in the long run.

Re:Production server

[Anonymous Coward]

Indeed.

I'm genuinely curious what world this 'programmer' lives in?

'Developers' not having access to the production server? Like I would trust any one of the handful of infrastructure or helpdesk monkey's to not botch the code transfer. As a matter of operational security, I demand the ability to put the prod code into place! Goes right back to support. Whoever breaks it, owns it.

Must be nice to where this guy works, to have the luxury environment where EVERYONE you work with is as knowledgeable, if not more-so than you are, when it's your code being put into production. Stunning, really!

Re: Production server

[nasch]

That's exactly our process. Nothing goes to production without being tested in the test environment first.

Re: Production server

[nasch]

What if I ran my own company with no employees? Would I be "doing it wrong" if I handled production deployment myself?

Re: Production server

[nasch]

Well said.

Re:Production server

[__aaclcg7560]

Like I would trust any one of the handful of infrastructure or helpdesk monkey's to not botch the code transfer.

As an intern, I discovered a crash bug on the test server. My software engineer boss couldn't reproduced it even though we sat side-by-side and I reproduced the bug 100%. Since he couldn't reproduced the bug, he authorized the patch for the production server. A day later the production server got caught in a crash loop. Engineers determined that a deep fix was needed, took the production server offline for three days and the company lost $250K in revenues. My six-month internship ended without a job offer. One-third of the department got laid off a month later to make up for the lost revenues, starting an inevitable death spiral. My boss got promoted.

Re:Production server

[bad-badtz-maru]

If your software is in an environment subject to SOX regulations, a developer can't have access to the production environment, nor can they have the ability to put the prod code in place.

Re:Production server

[avandesande]

At the very least use a separate account with admin privileges.

Re:Production server

[phantomfive]

Yeah, even when I am the only person working on the project, I still don't give myself access to production. All it takes is a deploy script and a jenkins server, and you never have to touch that thing. Maybe to get logs or something. If you deploy more than once or twice in the lifetime of the project, setting it up will save time and make things easier.

Re:Production server

[nasch]

You mean log into my workstation with two different accounts, one for development that can't access the production server, and one for deployment that can? I wouldn't even know how to set that up but it sure sounds like a pain. Maybe you mean something else though.

Re:Production server

[avandesande]

Yeah it's meant to be a pain. I've altered things (configuration, sql tabs) that I thought were development items that were really in production.

Re:Production server

[nasch]

Too much of a pain. I would just log into the one that lets me get all my work done. I have a bright orange desktop color on the production server and black on test so I always know what I'm logged in to.

Re:Production server

[Anonymous Coward]

Have you submitted this to TDWTF yet?

Re:Production server

[__aaclcg7560]

Have you submitted this to TDWTF [thedailywtf.com] yet?

Nope. This is ancient history. Almost pre-Internet (circa 1997).

Re:Problems with pointers

[Anonymous Coward]

Well, that escalated quickly.

You are dead on right.

[Anonymous Coward]

You are dead on right. Thanks for writing much better what I was thinking.

This particular section highlights several of the working conditions that are standard in programming/IT and reasons for leaving this non-profession.

Ignore the naysayers, they are just more bosses who want champagne and caviar work for cat-food wages.

Nice try at gaslighting. We know what is up.

[Anonymous Coward]

Nice try at gaslighting. We know what is up.

You are just one more of those bosses (or their sycophants) who want champagne and caviar work for cat-food wages.

Re:Nice try at gaslighting. We know what is up.

[mark-t]

Actually, the demand I have upon employers is that they treat employees fairly and compensate them fairly for whatever work they ask them to do.... if the employer wants people to work extra hours, then he should be compensating the employees in some way for those extra hours, but people who are making a decent enough wage at what they do already are not going to typically care whether or not they get any extra remuneration for putting in more time than what they know they are actually being paid for. Studies have been done on this matter.... after a certain point, more money does not equate to more happiness or satisfaction.... but that does place a heavy onus on the employer to be treating their employees fairly and compensating them commensurate with their efforts and achievements.

Visit My Blog

[Mavis Wendy]

If you are interested in anime, you can visit my blog https://maviswendy.blogspot.co...

Re: 1. Rust ... 165. Rust

[Anonymous Coward]

Testestte

Re:#1 Don't read O'Reilly books

[TheRaven64]

Because, in general (and there are a few exceptions), they're poorly written, very poorly edited (typos and incomprehensible sentences scattered throughout) and written by people who either don't understand the subject or don't understand how to explain things (or, in some cases, both). O'Reilly got into its current position by undercutting other publishers, which it did by cutting costs throughout the process. Unfortunately, this included paying authors and editors less, which shows in their output.

Re:Problems with pointers

[Wootery]

Yeah, don't you hate it when someone with an idiotic political agenda finds a way to work it into every topic?

Re:#1 Don't read O'Reilly books

[war4peace]

Q: what's the resemblance between an engineer and a dog?
A: both have intelligent eyes, but none can express themselves.

(My father told me this, he's an engineer)

Fizzbuzz, clean code version

[Anonymous Coward]

You want small functions? You got em! And even here, at least one of the functions are longer than three lines...

Urdu.

[Hognoxious]

Was going to suggest Urdu, but it's already there at number 49.

There are Oreilly books, and then well...Oreilly

[Anonymous Coward]

There are O'Reilly books that are quite good, mostly classics.
I have read newer O'Reilly books, one writen by two ladies, about SRE and other two written by Indians that were crap.
I agree with others that O'Reilly is not what it used to be.

Re:Problems with pointers

[Anonymous Coward]

Yeah, don't you hate it when someone with an idiotic political agenda finds a way to work it into every topic?

Yes, but what I really hate is when idiotic people feed the trolls.

It's all hogwash

[mlwmohawk]

Some of these "things every programmer should know" are just wrong. They are wrong from their observations, their non sequitur conclusions, and their misunderstanding of computer science.

BAH!

Re:It's all hogwash

[__aaclcg7560]

[...] and their misunderstanding of computer science.

But not every programmer has studied computer science.

Re:It's all hogwash

[mlwmohawk]

[...] and their misunderstanding of computer science.

But not every programmer has studied computer science.

OMG, then they should not be working in the field. Computer Science is what we do.

Re:It's all hogwash

[Cesare Ferrari]

Actually, no, what lots of us do is solve real world business problems by automating them using computers. Knowing what the business problem is is just as valuable as understanding how computers work, and you can approach the solution from either direction - neither is implicitly better than the other.

BTW, I'm a CompSci, but I work with Physics Phd types who understand the problems I work on better than I ever will, and we have complementary skills.

Re:It's all hogwash

[__aaclcg7560]

OMG, then they should not be working in the field. Computer Science is what we do.

I can't imagine too many CS graduates who want write a PowerShell script to ping 80,000+ workstations and output the results to an Excel spreadsheet.

Re: It's all hogwash

[garethjrowlands]

I am and I can. I think your statement is more about your imagination than it is anything else.

Re:It's all hogwash

[mlwmohawk]

The point I was making was not that every programmer should be a CompSci grad, but at least study the subject matter. I'd rather have a curious high school kid trying to improve their skills by reading Knuth and Stevens, than an incurious compsci grad.

Re: It's all hogwash

[__aaclcg7560]

I am and I can.

No, no, no. Real CS graduates get into a hissy-fit when asked to write a PowerShell script. That's not... computer science!!!

Re:It's all hogwash

[Cesare Ferrari]

Yeah, agreed.

Re:It's all hogwash

[Anonymous Coward]

But then how am I going to make a name for myself, reinventing the wheel??

Re:It's all hogwash

[michael_wojcik]

This is a perfect response. It's angry, confrontational, egotistic, and completely unhelpful. Bravo!

I can't disagree, though. Software is already nearly error-free, and I've never seen a programmer who produced anything other than excellent code. If O'Reilly can't publish a book of programming advice that's perfect, they shouldn't publish anything at all.

Re:It's all hogwash

[mlwmohawk]

Dismissing something as useless is a public service (and quite helpful) if it is, in fact, useless, as this stupid list assuredly is. There may be one or two useful pearls of wisdom embedded in what is otherwise sea of nonsense. So much so, maybe the wisest thing a person can do is read the list and understand why it is stupid and wrong.

I have tried reading them and they are all trite and poorly thought out.

Re:It's all hogwash

[Anonymous Coward]

I can't imagine too many CS graduates who want write a PowerShell script to ping 80,000+ workstations and output the results to an Excel spreadsheet.

I can't imagine too many CS graduates would bother writing that themselves, now that it's already written, and turned up with a simple google search. That CS grad would use the existing code, and probably spend their time on more interesting work while the script runs and collects data.

But hey, we know - if you didn't write it, it must be terrible.

Nice backpedaling. Still insufficient.

[Anonymous Coward]

Nice backpedaling. Still insufficient.

Why don't you expect employers to be *passionate* about paying (not just wanting to, but actually paying) professional programmers the most they *possibly* can? That would be in line with what you expect from the workers. Still would be a power imbalance, but hey there it is.

It's a double standard. A capitalist wants the maximum return for the minimum outlay.

In a capitalist system the worker should be looking for the maximum salary for the minimum outlay.

Alternatively, in your supposed "fair" system a worker would provide a "fair" amount of work in return for a "fair" level of pay. Not kill themselves for slave wages as is increasingly becoming what this non-profession is heading towards.

See the replies to you from others for more explanation and refutation of your lopsided, fairy-tale attitude.

Re:Nice backpedaling. Still insufficient.

[mark-t]

Why don't you expect employers to be *passionate* about paying (not just wanting to, but actually paying) professional programmers the most they *possibly* can

Not necessarily that most that they possibly can, but certainly no less than what the employee is rightly worth, given whatever it is that they do for the company. If an employee believes they are worth more than the employer is paying, they should rightfully try and secure alternative employment. In the meantime, however, failing to perform to the best of their ability at whatever task that has been set out for them regardless of how much they might have been paid to do it it is a failure in work ethic, and that failure is going to impact their chances at the jobs that are better paying than the one they might have right now.

What I would expect both from employers and colleagues is integrity, empathy, and humility.

Re: Problems with pointers

[Anonymous Coward]

Its called java script

Re:Poop

[RockDoctor]

Shouldn't you be teaching advanced Haskell Agile Buzzwording to the first-trimester ftus to get that competitive advantage in the workplace of 2025?

Once again - double standard.

[Anonymous Coward]

The employer only has to pay what the work is worth (in their estimation).

The employee has to do "the best they can" no matter how poorly (or well) they are paid.

It is a lopsided attitude, and one that puts impossible pressure on the employee.

You keep talking about integrity, empathy, and humility. I don't think those words mean what you think they mean.

Especially empathy. I see none in your attitude.

Re:Once again - double standard.

[mark-t]

Actually, the only thing the employer *has* to do is offer enough money that he can find people who will do whatever job it is that he wants done. This does not have to be anything resembling what he thinks or even knows that the job may actually be worth. The only thing the employee *has* to do is fulfill the expectations of work completed that the employer has on him. That's it.

I am suggesting, however, that these are merely the minimums that one can offer at a potentially sustainable level... it's a pitifully low bar, and if it as high as anyone ever reaches, then I can only suggest that they are probably never going to be happy with themselves or their choices, or probably almost anything in their life, which is truly unfortunate. Ideally, an employer pays what an employee is *actually* worth, and not just whatever minimum amount they might be able to get one for, and the employee actually cares enough about the quality of their work that any extra time that they might spend on it without any addition remuneration is going to be inconsequential to them (because the employer is already paying them fairly anyways). This ideal is the standard that I hold to, and I do, quite frankly, think that people who settle for less either have too poor a self-esteem to believe they are actually worth more, or else who simply do not have the integrity to maintain a positive work ethic that is transferable to *ANY* job, regardless of how much money it may make a person. It is, I am sorry to say, an ideal that is not always achievable, but if I do not reach beyond whatever standard I know I might achieve, I know I can never discover my fullest potential..

Re:Once again - double standard.

[Anonymous Coward]

The only thing the employee *has* to do is fulfill the expectations of work completed that the employer has on him. That's it.

I wish that were true. I would love to show up at my workplace, do my work, and collect a paycheck.

But noooo, they make me do "team building" exercises. They want me to do Myers-Briggs and Strengths Finder. They want me to attend brown bag lunches, kiss ass at company outings, play Secret Santa, watch stupid rah-rah videos from the CEO. They want me to be ENGAGED.

I don't want to be engaged, I just want to do my job. Leave me alone!!

Re:Once again - double standard.

[mark-t]

I said that those were the minimum standards that are potentially sustainable on a job, not that those standards are necessarily actually going to be considered sufficient by anyone.

Re:Problems with pointers

[Rakarra]

I wish I had mod points. This is a delightful trolling.

Re:Personal responsibility? Why not start at the t

[Anonymous Coward]

I just f*** love it...

I just fuck-love it!

Re:Problems with pointers

[Wootery]

You got me.

Re:Personal responsibility? Why not start at the t

[Anonymous Coward]

Where's the guy taking "personal responsibility"

b/c they're all special snowflakes looking for government handouts!

Re:Number 166

[Anonymous Coward]

Shame really, they would have killed your parents as 'defectives'.