azanar

At least in the case of tropical cyclones, I am having a really hard time believing that we will be able to prevent their formation, and still be able to emulate accurately all of the various effects they have on the planet. We'd have to build systems to advect heat from the ocean to the mid-atmosphere and mid-latitudes, rain to places where the storms no longer go. We'd have to find a way to prune all the weak trees these storms naturally prune. The same argument is made for the infrequent windstorms Seattle experiences; it keeps the forests healthy by knocking down the weak and sick trees. We've have to do this identification and pruning by hand, not just in the tree farms, but in whole forests.

This is the kind of education I'm hoping for. Not telling people we can't control nature and that is the end of that, but explaining, with as much depth as they would like into the theory, that attempting to define a new equilibrium for a particular system on this planet runs the risk of other equilibria being redefined as well, and also needing to be controlled; these in turn may redefine even more equilibria, ad infinitum. Maybe "can't" is the wrong word here, maybe what I mean to say is "you don't want to".

What such a philosophy fails to take into account is that these forces aren't just destructive. They represent a system that has a certain equilibrium which is maintained by periodically removing excess energy that has been introduced. Sometimes this surplus of energy is quite considerable, and so the transfer of that energy results in damage to things along the path.

It is possible that going the other direction might work for some things; force the energy transfer to occur more often but less severely. However, even this might have unintended consequences. Less powerful tropical cyclones may not survive to areas as far inland that may depend on their seasonal arrival for necessary rainfall.

I think the best thing we could do is educate people that certain things are not and will never be in our control, and that our reaction should not be panic and sensationalism but cautious respect and preparation.

As I've understood, the hurricanes that form every year are actually part of a process of advecting heat energy from the surface tropical regions to the higher altitudes and higher latitudes. I remember seeing a ocean temperature analysis just before and after Hurricane Rita traveled across the Gulf of Mexico, and the drop in ocean temperature was quite noticeable. Similar drops, to a lesser degree, can be observed with all tropical storms.

This process is really important to keeping temperatures around the planet more balanced that they would be otherwise. It also keeps the temperature of tropical oceans somewhat in check, so they don't spawn even more energetic cyclones later on. If we start trying to control this, there is the risk that we will screw ourselves by making tropical storms less frequent but much more severe.

See if there is a language that is further upstream than the rest, and also see if there is a language that is such a paradigm shift from the rest, and perhaps even from typical human-thought patterns, that many people from every group struggle to learn it. For those who don't, see if you can discover what is different about how they reason their way through programming.

Or perhaps find the language that everyone just gets once they've been exposed to one or more other languages. See if it really is the easiest, and more sparsely featured of the bunch, or if it just does a remarkably good job of unifying the concepts from all the others.

Just a couple of thoughts as I read your comment. :-)

He understood that there was a relationship between the array and the counter variable, but he took the relationship to far. He thought that the counter variable needed to represent the element of the array, and so he was assigning the value of the particular element in the array to the counter variable. In his mind, the counter variable didn't just provide the element number to look for; it was the element he was looking for, or at least it needed to become so.

Both this, and the color example provided by the author, demonstrate how many implied relationships we depend on within the programs we write, and how many people believe that those relationships to be explicitly stated or else the compiler won't understand what we mean.

I don't think I was able to get my friend to really understand what was going on and why we couldn't just 'tell' the computer to 'relate' these two things for us. It was a level of such naive concreteness that his mind just fought against descending to. I wonder how someone might educate people in thinking at this level? The optimist in me says it might be possible; the pessimist suggests that it might be in the same realm as trying to get people to understand pointers and recursion, which enough people I've read suggest is extremely hard for some (many?) people to understand.

There are many brands of mediocre programmer, some of which would claim a finished product well before the good programmer. But, the code will prove a nigh-unmaintainable disaster that will required all sorts of time later when a new feature is requested or bugs start creeping out.

There are times when a good programmer will take considerably longer than a bad programmer, and might spend time futzing around with different implementations, moving code around, creating various data structures, etc.

Depending on the task, I would argue that can be a good thing. The good programmer is attempting to understand and present a clear conceptual model of the problem and solution in his code; the mediocre programmer might just create a litany of special cases for the cases specified right now just so they can get that particular program behind them.

Although the mediocre programmer might produce code faster, I would argue the good programmer is still 10x more productive, because he has done that much more thinking than the mediocre programmer. Perhaps when you refer to futzing, you mean changing the code just for the sake of another commit to show management, where nothing is learned and nothing is improved.

Also, a good programmer might come back two months from now, with the knowledge he gained from some other project, and make a change to the program that tangibly improves it for the better. The mediocre programmer will have put all that behind them; it is not on their list of projects and requirements, therefore they won't bother, nor will they bother even mention it to anyone.

But, I suspect this sort of comparison of timespans varies with size, and with the difficulty of the problem space.

And yeah, N^2 different answers. :-)

So do the much of the other 40% percent. Does someone wanting to get things done and the passion to get interested in what they are working on immediately make them a promoter of an agenda that is not their own? Is what we decide to work on always a product of external expectations? If so, I suspect your understanding of human behavior is faulty. Not everyone works for money because they have people depending on them or a company line to toe. Not all of this is about deciding the more noble sacrifice, or even about sacrifice at all, ok?

Developing skills is good; having integrity is good; being a professional (whatever that means) can be good. But if you make what you do just about the paycheck, or if you justify that stance by waving at other people who depend on you, I don't know that I can consider that a stance that demonstrates integrity. It demonstrates a willingness to sacrifice, for certain; this is something you consider very noble. But sacrifices can be made for reasons that are anything but noble, and even sacrifices that are noble are not necessarily ones that are wise.

For instance, you raise the point about raising a family, and the way that makes a person become a 60%er. Quite frankly, I wish I would start seeing people around me sacrifice less to their families. Of the men I have met who are married and have families, I can't say that all or even most of them are happy with the balance they feel forced to make. It is almost as though the family goal, or at least the degree to which they feel obligated to focus on it, was foist upon them by someone else. They want to focus on other things too, but they can't and not risk having people sneer at their “bad parenting”. I have recently had to endure a good friend going through a divorce, brought on because he sacrificed his creative spirit to be the family man. It was very noble of him, but it was also amazingly dumb as he learned in hindsight. His family would've held together far better if he had pushed harder for time to be creative and accomplish his other goals in life. Instead, he let it fester, and it imploded in his face.

And as for my parents sacrifices to me, I do remember, and I wish they had made fewer or at least different sacrifices. I would happily give back a number of the presents they gave me when I was younger to see them happier and personally more fulfilled more often. I would not have minded a smaller house, less privacy, fewer toys, or similar withholdings if it just meant I could look back and not feel like such a fucking burden on them. I think it would've allowed me to develop a more positive outlook on life and what it has to offer sooner, rather than having to realize on my own later on that a lot of this self-sacrifice people do gets us largely nowhere.

So no, this is not all about picking the sacrifices we make, with the realization that in the end we're all gonna get screwed and have to except the sublinear returns we do get. It is about realizing that how we treat ourselves, and how much we make sure we are feeling fulfilled in life, has a huge bearing on how we treat those who we care about and who care about us, regardless of the bullshit we tell ourselves about how we can strictly segment our lives. All that is bollocks, and it has real consequences; just ask my now freshly single friend.

I really wonder how often these three traits are all found in one person. I have a hard time imagining a person being passionate and able to get things done, but being willing to move forward at a rate mandated by the rest of a large, bureaucratic organization. Perhaps this is the group of people that is competent but also feels a stronger obligation to those they support to have something stable.

My reaction to this is slightly different than the authors: I actually find myself fearing for the human condition. Whenever I meet these people, I find that they are often on the brink of ceasing to care. They'll keep their skills, and keep learning new ones, if only because they are insatiably curious. They'll remain patient, because what they are dealing with at that moment is likely the hardest test their patience will have. But, they'll lose the passion, either because they tire from constantly pushing against the elephant, or because the feeling of obligation will force them to, so that they don't burn-out and potentially leave those who depend on them unsupported.

One might argue that their passion isn't lost, it is just redirected to other things (children, family, other hobbies, etc.). This I have a hard time believing, because I've run into people at small, young companies who are passionate about their families and hobbies, but they are also passionate about their work. These are the people that make me believe a little more in the human condition; they are the ones that have decided that sacrificing their fulfillment, although noble and heavily encouraged socially, has its own risks that are not trivial. It's possible that they can be fulfilled just by family and other hobbies, and their work doesn't have to matter. If they can't, depression will fill the cracks, and will bleed over into every part of their lives, in spite of how much they may claim success in compartmentalizing. Even if they can, treating this as a zero-sum game seems broken to me, if for no other reason than the people I've known who are counterexamples.

I suspect this is what you are asking for. This page has links to a number of time series database systems.

The why might remain obscure, but that depends on two very important things: your documentation, as you noted; and your data structures.

Show me your flow charts and conceal your tables and I shall continue to be mystified, show me your tables and I won't usually need your flow charts; they'll be obvious. - Fred Brooks

As much as you can organize your data to make the purpose of it obvious, do that. It will make the system far easier for a new-comer to comprehend, and will make far more obvious to do you the sort of code you need to write to make the wheels turn. Where that is not enough, then use comments, but don't assume that prose is an adequate replacement for precise and logical data representation. Often times, I've found that the latter is a far better choice.

If the people who hired her were thinking straight, they hired her for more than just her ability to write code to a strict specification under strict supervision. A number of developers are valuable far beyond their ability to make a computer do their bidding, and the employer who does not care does so at their own peril.

She may come off as a little overbearing, but I don't get the sense that she is unreasonably set in her ways. I get the sense that she's passionate about doing things right, and will take up issue when something doesn't make sense and push back until things do make sense. If you think these are the same, I'm afraid your model of developer behavior is flawed. Strong beliefs can be weakly held.

And it is possible that refactoring code that works is worth $XXX/hr. Consider the savings that might be accrued later on due to shorter bug-fix cycles, quicker feature releases, and less overall malaise of the development staff. Not everyone can be motivated by having their paycheck treated as a carrot on a stick. So the money might be very well spent.

But it might; that is the other half of pragmatism. Being pragmatic is not just a softer way of saying self-defeatist.

And don't be so dismissive of theory. To quote W. Edwards Deming: "Experience by itself teaches nothing...Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence without theory there is no learning." Just doing what you discover is done in practice provides absolutely no room for improvement outside of rare flashes of intuitive brilliance. Theory is not just an abstract description of what has been observed concretely so far; by far the greater value lies in the ability for theory to predict what has a likelihood of being observed in the future. Having a theoretical basis to work off of will give those experiences context, and will give you the ability to do a much deeper analysis. And analysis, if the comments Sara received are any indicator for, is something we need to be doing a lot more of.

I wish I were learning it was even that easy. Maybe it is, and I'm just thinking about it too hard.

To borrow your analogy of the can of worms module, that it runs well but will become a bomb as soon as someone decides to rewire it fills me with a sense of deep dread. My mind immediately drifts to the scenario where something forces changes on that module, such as the server continuously crashing due to a latent schrodinbug that just surfaced, but in a time-frame where those 47 issues just can't be resolved. I've never been comfortable with the justification that "it works now, so just don't screw with it." It seems to just be begging for Murphy to make a fool of the person justifying a decision thusly.

I used the analogy of technical debt being called in a post a few months ago to describe this situation. Granted, my experience as a developer is still somewhat limited, but I have seen people with years of experience get completely hosed by deciding wrong; sometimes deciding wrong a lot. I've also seen people with just a couple of years of experience pick the way to go with decent accuracy. This makes me wonder if there is an intuition certain people have that experience hones, but that experience alone does not completely replace.

They seem to encourage the original poster to adopt a short-term, sycophantic perspective where she punts her desire to keep the code-base clean and maintainable in exchange for blindly following requirements and putting forward a good image. I know there are a certain class of people who recoil in instinctive disgust at the suggestion, even after being reasoned with and beaten down; I am one of them.

One of the posters even mentions the books that talk about this sort of thing, and then dismisses them as irrelevant to the true goals of management. Most of these books contain the wisdom of people who have seen many projects and products, and have a reasonable idea of what makes one successful from a technical stand-point. The reason they were written is because the authors saw enough projects fail when not following the practices they suggest. It isn't just wishful thinking written by technically minded trolls.

Reading all these comments I am reminded of the first section of a book I read recently which helped me realize I wasn't alone. I believe I have mentioned it on here in a prior post; Uncle Bob's _Clean Code_. One of the most salient points he makes in the first chapter is that the quality of the code-base is the responsibility of the developers, because they are the only ones who have the most concrete sense regarding the cost of bad code. In the long run, it will make everyone look completely incompetent, even if in the short-term things appear to be getting done at a very rapid rate. Eventually, your clients will care, your managers will care, and “I was just following orders” will not be an acceptable excuse because they were looking to you for intelligence and wisdom, not just units of work done without deep analysis.

Of the posts of his I read, it seems that he would go that direction only when someone else already painted themselves the victim of emotional hurt from his earlier technical criticism.

You could argue he should've reacted differently to this self-victimization, but I worry what that would do to the signal-to-noise ratio of the forum in question. If people who require emotional coddling are encouraged to participate in technical forms, then a lot of the conversations focus on that rather than on technical point.

ESR was not entirely wrong when he stated you can pick exaggeratedly "friendly" or useful; Naggum's goal was to keep the forum firmly planted in the realm of useful, even if it meant offending some people along the way. I think there is some virtue in this. Of the posts of his I read, there were nuggets of very good wisdom in all of them.

If it is the same set of 20 modules, but those twenty modules are not conceptually similar, that might be something worth investigating further. That those modules need to be imported might suggest that the current module is attempting to do too many things at once.

I only point this out because a former coworker's code I've been dealing with. This was in PHP, but everything had been broken out into classes and the classes were named after the files. So, closer than just including raw PHP code into the same scope, and hopefully close enough that I don't get buried in comments to the contrary. :-)

But the coworker had the logical extreme of a module importing module. Arguably, he had the same 120 files coming in over and over. But this created all sorts of problems, the most prevalent being that a typo anywhere in these module files would bring down the entire site, since they have to be syntax checked.

So, I overall agree with jerf, with the addendum of be vigilant and be careful. :-)

Cohesion is a problem with xeroxed articles. Not to say it isn't with most textbooks, but it can be one of their primary goals, whereas the primary goal of an article is to disseminate a set of ideas in as efficient a way as possible, with some assumptions about prior knowledge of the reader.

I remember sweating through problem after problem in calculus so I could do problem after problem on the tests.

So did I. Part of internalizing the fundamentals of a subject is working through exercises that depend on those fundamentals. You don't get that when something else is doing the work for you. Learning isn't easy, and we need to get over the desire to want to make it so.

Or, to put in another way, you are not mandated to attend a class where the professor will charge you to see a certain sports team play. Somewhere along the way, you made a choice that brought you to this mandate.

It seems your Dean would've been good friends with Upton Sinclair.

Although, it does raise what I think is an interesting question. It has been said on here a lot that markets tend to see monopolies as market damage, and route around them; this isn't quite that severe, but seems to be a vertical monopoly to a certain degree. How would one route around this? The obvious option would be "go to school somewhere else," but this seems endemic in academia as a whole.

Given that Tor has been available for a while, are there examples of maintainers of Tor end nodes being held accountable for the traffic they pass on behalf of others?

This seems bred the same philosophy as holding an ISP accountable for the traffic of its customers, or holding the administrator of 4chan accountable for what is posted on there. It seems tenuous.

Maybe I'm missing something. How many jurisdictions are there now where an unknowing facilitator can be held accountable for the criminal acts of those he is facilitating?

Either way, I'm not fond of this philosophy of scaring everyone into the clear simply to avoid gruesome labeling.

Or you've tried to get some control, and have had your hand slapped away. And then realize the part that you don't have control over is the crux of the product's value proposition, and that it is a bad value proposition. Having control of the how isn't going to make it valuable enough, because it doesn't solve the right root problem. If you've ever tried to push a certain direction, only to have people respond "that is management's decision, not yours," that's what I am referring to. Perhaps you have never experienced that.

"If anyone else ever produced a specification rigorous enough for me to code from, I could die happy."

That's not quite what I meant. My point is that, in a large number of development shops, this is the way people deliver value. Their manager and the organization he represents is the customer, and often times they already know what they want, even if it is the wrong solution. It comes in the form of a specification, even if that is badly written. The value they bring is their technical skill set, such as it is, because most of the other decisions regarding the product have already been made by the time it gets to them.

I'm not ascribing this method of delivering value to you and those you know, nor to I and most of the programmers I know. I'm ascribing this to the people in the stories they and I tell of the other programmers we've met who operate this way: offering technical skills, and otherwise having faith everyone else will figure out the customer value part. Some are getting Darwined, as people find out they don't even provide what they claim to offer, but enough people out there find good value in a cog.

Specialization is not free; it decreases flexibility, and would seem that it would decrease cross-pollination of ideas from different areas of knowledge. It increases income, for sure, but also increases the attendant risk that people won't have need for an X specialist right at that moment, or at least no one you would want to work for.

I'll grant that generalization is not free either. Someone who really needs an X specialist will pay top dollar, because the supply is likely pretty low. And people may not trust a generalist to go and implement some specialized X performing application.

I think there are opportunities and attendant risks for both. I really don't think either one wins outright. But, I'll be happy to listen to words of wisdom you might have on this.

http://thedailywtf.com/articles/up-or-out-solving-the-it-tur...

FWIW, I think there's enough people in this audience that wouldn't be happy holding on to a job they aren't particularly interested in keeping up to date on, simply because they have the domain knowledge to make them "safe". I could be wrong though.

Come on now, what basis do you have to say that someone who is a generalist is unable to provide value to people through the software they write? Do people need to be excessively specialized to make something people will pay money for?

And for that matter, I could see the generalist programmer fairing better, because they don't lose the general theory things are based on while diving incredibly deeply into a narrow body of very specific knowledge. If the job/labor/consumer/whatever market presents some new area of need, they're in a better position to go learn and capitalize on it.

It might more than you give it credit for. I realize, though, that it is socially a faux pas to not provide that caveat. I know I've been called out once or twice for not condemning risk taking in the context of a family.

That being said, having a family doesn't require that you start hoarding possessions. It does mean increased expenses, and increased responsibility, and probably not being able to live analogously to a student. But a couple I and my wife are close friends with do not own much more in the way of possessions, and are with two kids with a third on the way. It meant that when one of them became unemployed, it wasn't a huge deal even with the kids, due to the financial position that frugality created for them.

I think even people with families could take something from this article, even if it isn't with the same gung-ho intensity someone who is bachelor might.

I'm especially annoyed by this point: "In this type of economy getting a job is tough if not often impossible." This flies in the face of the rest of his thesis of point 2, which is to go try many different jobs until you find the one that is right for you. I don't see how these two behaviors can coexist unless you are becoming the waiter at your own restaurant, launderer at your own cleaning storefront, freelance door to door vacuum cleaner sales man, and a night janitor for each of these, all in a nine-to-twelve month period.

And then the usual nod to "this kind of economy," which has some amount of truth as a compounding risk factor, but has become the universal justification for refusing to change anything.

But, within the platitudes, there are some good ideas.

If you are after flexibility, then, as much as you can, live like a student. He's not the only one to say this, but it is true. Doing that will increase the rate you are saving money; enough of doing that, pretty much anything, including going income-less for a while, doesn't seem that irresponsible anymore.

"If you love what you do so much that you are willing to continue to live like a student in order to be able to stay in the job, you have found your calling." Maybe, but don't undersell yourself, either. What you provide has value which you should get some benefit from, regardless of how good you might be at rationalizing.

Finally, I disagree that everyone is a poor judge of their own abilities, and especially that everyone will overestimate. Plenty of people are, granted, but not so many I think a blanket generalization is warranted.

From my experience, a McD's is just about as noisy as a Starbucks on an average day. If I want to work on projects, I generally aim more for the local, less-commercialized coffee houses.

Is there an ambiance factor to this, or is it more of a psychological distinction between fast food places and coffee houses in general? Or is there something else?

For instance, a secretary who has a friend who is "really good with computers" who submits her resume for a job as a DBA, and that friend gets hired on the basis of that recommendation -- yes, the friend was someone I knew. I guess you could say the friend earned the job based on the criteria put forward, but not on any basis that is good for her, the company, or the DBA profession as a whole.