You mean you do potentially mass commits before checking, or even before compiling or running unit tests because problems with compilation and unit tests can - and will - occur when refactoring/renaming of artifacts is done wrong?

Coding something that one can easily get wrong (bad regular expression) and spending time debugging it when you have already built-in functionality typically coupled with a transparent mass undo? You are such a professional.

None. When I go to Japan, it is impossible not to notice how intelligent people are. Intelligent as in being able to express themselves, to think, reason, and synthesize positions out of multiple sources of information. This is not to say there aren't ignorant dumb-asses over there, but you can tell that basic, common education delivers over there.

Here, education is quite unequal. Some schools have nothing to envy from countries like Finland, whereas other schools churn graduate kids who cannot add fractions or read an Op.Ed. Student cohorts that gravitate to the later condition tend, IMO, to be the ones least likely to understand the benefits of technology.

Before we even get to the point of teaching technical skills to kids, we need to first worry about teaching them how to reason and operate effectively in a literate world. When they do that, a whole world of thinking opportunities, tasks and problems requiring solving comes into existence.

That gives a context in which technology can be applied. Better yet, people that are already literate begin, on their own, to apply technology to their needs. Beyond that, HS kids need to know the basics of computer security (recognizing spam attempts, running an anti-virus, backing up data on thumb drives, etc.) and basic usage of spreadsheets and word processors.

The last two (spreadsheets and word processors) can only be used effectively in a "problem" context. You use spreadsheets to create a balance, or budget, or to track expenses, or to calculate your mortgage rate, or how the cost of material and labor in making a home repair. That comes with a good understanding of arithmetic and algebra applied to real world problems (such as personal finance).

And all that comes from the capacity of engaging in abstract thinking. Form follows function. The form of solving a problem (using technology) follows function (the need to solve a problem). And a person cannot envision a problem or a need to solve it if he/she cannot think about it in practical, useful and abstract terms.

It is if it causes mass unemployment. The industrial revolution did show us how to do things in more economical (and at times safer) ways. With that said, for the first 30-40 years of this period, by several estimates, about 1/3 of the working class was employed, 1/3 permanently in a state of half-employment, and the remaining 1/3 in a permanent state of unemployment, with nothing but scrapping by.

Let those numbers sink in. Poverty increased among the lowest sectors of society, in large numbers. It took decades for markets to "heal themselves".

We can give economies and societies of the time to not give a shit, or not even understanding the implications because, well, people act according to the times.

But what is our excuse now. I am not against modernization or globalization, but by God, private entities need to do a better job at looking at the consequences (which, if you play it right, can actually become profitable opportunities in creating new markets in which the unemployed transfer to work.)

And if private entities cannot or do not want, the it is up to the State. Because someone has to. This isn't the late 1700's, early 1800's. If we ever fall for the last option, we have only ourselves to blame.

And anyone who things the negative impact of change is negligible simply because change is gradual also misunderstand how markets work. These damages take decades to get undone. And here we are talking beyond the mere concepts of markets. We are talking about national policies. We have been taking purely market-driven ideological points up our asses for the last 2-3 decades without any national policy to handle the aftermaths, and see where it has taken us.

People that revolt from a position of abject poverty and unemployment are extortionists?

We do not get anything in return? How about this? We don't get our heads on a pitchfork. Put millions of people out of work and bad violent shit is bound to happen. Fucking history is right there to tell you this. How stupid can we be that do not see the self-preservation benefit of not putting millions of people out of work?

This is the stupidest false dichotomy bullshit I've seen in a long time. No one is saying no to automation. What the concern is, how do we plan to introduce automation in the trucking industry while simultaneously handle the 10 +/- million people that will be affected? Do we just introduce automation and let markets self-heal (which is pretty much dog-eat-dog), or do we put in place transition job and training programs to ameliorate the impact of unemployment until the bulk of people is able to transition into other job sectors.

That you miss the gist of the problem shows that you are not as smart as you think you are, or you simply do not care. Don't know which is scarier.

Been in this business for 20 years, 9 different companies in various industries, doing application and system/embedded development. But whatever. If you want to play my lightsaber is bigger than yours, by all means, knock yourself out, you win.

We are obviously talking about processes in general. But if we want to talk about shitty IDEs, languages and coding-level artifacts, let's do it. Yes, there are shitty IDEs, bad languages and such. They make work difficult, if not painfully insane, but none of that stop good workers from delivering good work (or at least avoid the number of sophomoric WTFs from piling up.)

Back in 1994, I once had the disgrace of having to do support report generating programs on PICK systems, using nothing but ed (not even vi for ${DEITY:-FSM} sake), using a bastardized language that mixed sh-based constructs with SQL-like statements for multi-column databases and PICKBasic.

That last thing, PICK Basic, utter crap that made GW-BASIC look like Haskell. At least GW-BASIC supported named labels for your GOTOs. PICK Basic oth only supported numeric labels. Imagine that if you can. You can have named labels in most assembly languages, but not in PICK Basic. Wrap your head around that if you can.

Anyways, the existing programs were a monstrosity we inherited were a monstrosity. We started fixing that by establishing standards and procedures for creating new programs (or introducing changes in new ones). We established a hierarchy of numeric labels - labels in the 1000-1999 range for initialization, 2000-2999, 3000-3999 for general computation, 4000-4999 for reporting/output and 5000+ for error handling and abnormal termination.

Those are the tools we had for that specific job, and as ugly as they were, we found ways to deal with them, to increase value for our employer while minimizing the number of WTFs that had been piling up for years by incompetent code monkeys.

There is no question in my mind that PICK systems were pure crap because they required us to put significantly more attention to detail to avoid introducing WTFs. Thank God that was just one job I had to do, and that I have never had to deal with that ever since.

And I've experience deja-vu moments like that, in Java, Visual Basic, C/C++, FoxPro, you name it. There is no language or IDE out there that does not have some unbelievable collection of WTFs.

But none of them cause people to unavoidably fuck it up again and again and again. Wielder, not tool.

When we had our choice to pick, we try to pick the best tools we can get.

But more often than not, we do not. And when that happens, what do you do? Do you go on auto-pilot and let the tool WTFquery imbue themselves into WTFs in your own code?

No. Not at all. You use your skills and find ways to make that shit work, to put some structure, some standards, some sane mechanisms and patterns and practices to maintain some quality in your work.

It can be done. Actually, it is done, and it has been done. Wielder, not tool. Always.

I didn't say every tool is perfect. I said that every tool has a function, has a context, and that works in that context. But hey, I guess I have to go Barney Style in these realms.

Why would you use a hammer made out of plastic straws? What is the use of that tool? What is the purpose? What is the context? These are obviously rhetorical questions used to highlight the stupidity of your counter example.

For that matter, why don't you go and say "good luck hammering nails with a bar of soap, a saw, or a roll of toilet paper"?

Which is true. But here we are talking about tools, concepts and processes that are known to produce good results when used intelligently (or that should be known by anyone worth his/her salt in this industry.)

The context should have been apparent, but I guess we needed to go Barney Style with it.

Be careful here. A cert's worth is not defined simply by the lessons that come with it. It is also pixie dust or glitter that you use in your resume.

I'm not joking. During the last recession, I became unemployed (just 7 days before my first child was born). I had the skills, and references, but I could not make any progress in getting interviews with my resume. Then it dawned on me to call one of the recruiters I was using and asked her if I could see the resumes of the people her firm has placed in jobs in the last few months, the ones with the better salaries (names and personal info blacked out of course.)

Every single resume I saw had some type of certification it it - SCJP, ECSP, whatever. I worked on Java for a decade, but never cared for certificates. But when I saw the resumes, I immediately took the SCJP exam, nailed it, and put SCJP certificate # on my resume.

That was the only change I made on my resume. And voila, I started getting calls.

At any given time, but specially during economic downturns, there is a ton of people looking for jobs, and HR departments get bombarded by them. And they rely on keyboards and certs to filter resumes to a manageable number.

It is stupid. It doesn't guarantee shit. But it is what it is.

In this career, anyone should expect a downturn once a decade (if you are lucky), or two or more if you live in an area with crappy local economies. So protect yourself by getting a few certs specific to your career (or the ones that are more popular in job searches in your area of residence.)

They don't make you a better programmer, but they can give you an edge in passing the moronic keyword filters put in place by HR departments.

It is stupid, but unless you live in a robust job market like SV, it is what it is. That's my personal anecdote. YMMV.

No. It's just that people suck at doing quality work. People released shit when using procedural/modular programming. But that's people, not procedural/modular programming. Then OOP came, and people did more shit with it. But that's not on OOP, but on people.

I can say that with confidence because I know teams and companies that have delivered quality work using either any (or all) of these paradigms.

Same with processes. People have done good work with waterfall, and bad work with waterfall. Good work with spiral/iterative process, and bad work as well. Same with RAD, RUP, all flavors of agile, XP, Scrum, Kanban, etc.

It is people. It is organizations. A group of engineers that do good work with one reference process is very likely to do good work with most other processes, newer or older than the reference process by which they are currently being measured.

Newer processes are typically better than older ones when applied to general cases. Better as in helping ameliorate cost or increase delivery, or pretty much optimize some type of software development KPI. But that neither implies older methods are bad or that newer methods guarantee better deliveries.

It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.