Half of the devs from there that I was in contact with were not capable of:

- googling a solution to a problem efficiently. When they hit a wall, they turned to me with an empty look like they were lost.

- read an error message to troubleshoot. A stack trace is utter mystery.

- use effectively the UI of their laptop. Some can't even Ctrl + S to save, they look up the "save" entry in the menu.

We are talking about people writing code every day, in several programming languages: fortran, c, c++, java, Python...

Because I'm a freelancer, I don't care. I'm paid extremely well to be very nice to them and solve all their problems.

But I'm very glad I don't have to be held responsible for anything those people end up putting in production. And I have no reason to believe it's different in their security department.

However, and this is a good lesson to all of the geeks like me that think work is about doing the right thing: the output they produce is good enough in our society. Its cost/value hits the sweat spot. Business is not about doing things right, it's about being profitable.

If you have one scandal a year, but it costs you less than making sure you have a secure system, and you are not legally challenged, then you are golden.

In fact, the chances to have even one scandal are very low. Actual risks of failure or attack are low. And consequences in case of crisis are low too. People don't care that much about privacy, cyber-security, etc. And policy makers won't enforce their laws anyway, at least not to any extent that will endanger the company.

So if the software allows people to do their job IRL at a reasonable price, under an acceptable deadline, good enough.

In fact, David Goodenough is a very funny French meme: https://www.youtube.com/watch?v=ho4W5LnFl6s

I'm also a freelancer, and I've also said exactly this. I was happy to profit handsomely from the incompetence and apathy of my clients.

But in recent years I realized I was wrong. It doesn't matter how well it pays, I feel like I'm wasting precious chunks of a very limited lifetime being a disciplined and methodical janitor for my clients.

Now it's more important to learn, to stretch, or to contribute to a more worthy cause than just getting paid well to do shitwork.

Time well spent is worth far more than anyone will pay for it.

The unintended side effect of prioritizing learning over invoicing is that revenue now seems to take care of itself. It's all a bit Zen.

If the insist on doing it the way they want, I am happy to admit that they may well know more about the business than me and do it anyway. But I'd rather have a reputation for steering my clients in good directions with both advice and direct technical help. That way people will be confident I'm not trying to take them for a ride. Plus better technical specs out of it and clarity around what needs to be done.

The best one can do is be patient, and help them do with what they got.

- to them, I'm helpful. So I feel useful, because I got actual humans that are thankful that I'm here. I need that to live, to be happy.

- the money allows me to have a very good life style, so I can enjoy many things I couldn't otherwise in what you call my "very limited lifetime"

- high rates mean less hours, which mean I get to spend time with people I love, have fun and contribute to open source projects.

It's not perfect, sure. But it's pretty sweat.

I wish people would have told me that years ago.

One extreme example is there is this homeless guy who is a retired very good teacher who has a way of both teaching kids and correcting problematic behaviors. Unfortunately, he doesn't advertise and he doesn't up his rate ($20/hr IIRC). It's a shame.

Unfortunately, for me, being a do-gooder didn't pay very well.

I often wonder if I should have stayed in the rat race during my most productive years and then used that nest egg to fund my activism.

I honestly don't know.

Same with the people I help technically at work. They're all brilliant scientists. They get confused by the difference between VGA, DisplayPort, HDMI, and DVI. Or get extremely frustrated when a button on the UI moves.

I think software developers don't quite understand how big a deal it is to a 70 year old when the button to do something moves. Probably a quarter of my day is often just figuring out how to reconfigure things to their liking or else spend an hour retraining them because of some unnecessary UI change in Windows 10, after which they will still forget and ask for help again.

God forbid you break apart an application into multiple programs or have online activation or a license server. I think I hear at least a daily rant about how you can't just buy software anymore and now you can only rent it for a bit.

We have versions of software that are 13 years old because the publisher switched from an unlimited permanent license to a per-seat per-year license model. Rarely worth it when the instructors get confused by new software anyway.

Back when there were RS232 (aka 9 pin) connectors on PCs, my dad's computer had two mail connectors, one CGA and one serial port (I think it was a serial port, but I'm not sure, as those connectors were usually female). I took the VGA cable and accidentally plugged it into the serial port. When I turned on the computer, I heard the startup chirping noises, the screen was black for a few seconds, and then white smoke started pouring out of the power supply. I turned it off REAL fast :) Somehow the computer still worked after that.

EDIT: changed VGA to CGA

I don't see how that's possible without really crushing it in there. Also, CGA & EGA were the same connector as serial (DE-9), which would've been easier to confuse.

It could've been worse: I knew a guy in high-school who plugged a parallel printer into a Mac classic's SCSI DB-25 (the same physical connector as a parallel port, female on the computer; DB-25 serial is a male connector on a PC) and baked it into "apple pie" with that "lovely" magic smoke aroma.

My 84 yo mother was technically competent. Currently has mid-stage dementia. Long term recall still remains impressive. Apparently unable to learn new skills, habits.

Every software update is cleaving a few more things from her life.

My siblings and I thought upgrading her to an iPhone was a good idea, some years ago. Initially, sure. But now I wish we had a snapshot of her tech stack from her early 70s, and found a way to keep that working.

It would've been impossible to do this with commercial software as basically nothing has a 25+ year old support life. Because everything is open source, nothing needs to change.

The gesture controls Apple implemented starting with the iPhone X are also very confusing for an Android user, eve though I also use gesture controls on my S10.

But in the end, you'd get used to it as you did with Android.

I have paired up with some terrible programmers, with bad coding habits, weak knowledge of their ecosystem and no capacity for any kind of architecture design, but that eventually did better than me because they worked way more, and were more persistent.

This idea that bad code will waste productivity is not that important if one person accepts to work 30 hours more than you every week, including to fix the mistakes they introduced by writing said code in the first place.

If you can produce something working that satisfies the requirements you can't be terrible in my book, no matter what I think of your style

Agreed on the levels of complexity in basic apps nowadays.

Last time I stumbled on an "io game" built this way, the lack of WASM debugging tools made it very hard to hack at the game :(

Of course, people would say "what's the point" when JS is a thing and widely supported. I wonder if there'd be a) a compelling improvement in performance and b) a compelling improvement in reliability if we just wholesale replaced it based on lessons learned? I reckon even just keeping JS and eliminating implicit coercions would be a huge improvement (as well as maybe automatic semicolon insertion) and reduce the debugging times considerably.

I don't know about "less quirky", but Microsoft tried with VBScript. Google tried with Dart. Initially, Dart meant to be interpreted by the browser (not transpiled to JS). I'm sure there might have been similar, smaller projects, but Javascript-in-the-browser has momentum that's hard to beat.

I'm trying my best :D

    <link rel='stylesheet' href='res/lettercrap.css' />
    <link rel='stylesheet' href='res/style.css' />

In all my personal projects I just copy-paste past CSS from existing projects of mine to new ones, at most just changing two or three colors.

The number of developers I've worked with who handle broken builds with "The build is broken! Why did you break it?" instead of "I shall now proceed to read the error message which will helpfully tell me precisely why the build is broken and how to fix it" has always astounded me.

I've yet to find a way to handle error messages that will actually convince devs to read them. All I've found to date is apologizing for an unclear error message and offering to help with anything they had trouble understanding.

1. It took too much of my time. Since I was doing this in addition to my dev duties, it was not something I could afford to spend time on. 2. When I first started, I would resolve the issues myself. But I soon realized the builds were usually broken by the same suspects. Sending it back to the devs (and also requiring them to buy a box of donuts on breaking the build) put a quick stop to this. 3. Builds were usually broken by people checking in their code in a hurry right before they were done for the day. Calling them and having them fix it after work (as opposed to me having to sit additional hours after work fixing something they broke) very quickly put an end to the practice of checking in your code in a hurry and leaving for the day because you had a dinner to make it to. I don’t want you to miss your dinner, but if it’s important enough that you can’t be bothered to make sure your code is working then you can also wait till the next morning to checkin your code.

Except I do. And as with anything, feedback takes you back to reality.

Plus you learn where you tend to make mistakes and thus have a chance to study a bit more about area to learn how to not make mistakes.

- read a stack trace

- find things in the doc

- use the debugger

Most people, professional devs, signing up for my __advanced__, yes, specifically requested to be advanced, Python trainings, don't know how to do this.

Again, I try to be extremely nice about this, because nobody likes to feel inadequate and I'd rather have people learning happily this and improve their life and work.

It takes a lot of courage, if you are 40 and being in the field for 2 decades to admit you need to go back to this.

But it's not what I was expecting from the industry.

Hey, it makes me feel useful :)

So when you get to something that is complicated and has the potential for deep strategies and shortcuts for efficiency (e.g debugging), it's no surprise that experienced coders might want a refresher.

Impostor Syndrome may be a thing there, too.

E.g only "java.lang.NullPointerException", only the top of the stack, missing "cause" etc. :D

You have it easy, the devs here in Cardiff push code that doesn’t even compile locally, then start howling that “Jenkins is down!” when the build fails. Or even just “the server is down” with no other details. Like I just telepathically know which of our 5000 VMs is “the”.

My experience in learning computing in school was going through large months long projects where later stages built on early stages but the entire project was throughly documented and paint by Numbers so long as you followed the directions exactly. If you came up with a valid but undocumented solution you would break the assumptions of the documentation and forever be hacking the program to get it to work which was still possible just time consuming and nobody knew how to help you. The end result is students who can follow docs without fucking up but who also don't know how to fix things other than by rolling back to a known good version.

I've found these sorts of problems to be very difficult to solve in academics due to the need to standardize assignments and grading yet a few months doing an original project will infuse you with troubleshooting mojo.

Agreed. I was told, and later had to tell others something to the effect of "okay, so what did the error message say? did you search that?"

Moreover, having person who made bug is just good practice. Feedback, basically. When people know about own errors and have to fix them, they learn more about errors they make.

It perplexes me that you could get through a 4 year degree without learning how to read a compiler error message though. I'd be less perplexed at this happening in a super condensed and streamlined boot camp though.

Then again, neither was version control...

Only time I felt students got shafted was a Web Dev elective. People who weren't already pretty experienced with JS had a really hard time (we were on the quarter system, an HTML/CSS/JS+React/Redux+Node is pretty ridiculous to cover in one quarter).

If the expected cost of decoding the error messages includes a lot of reverse engineering of crap code, people won't bother.

It was a major, major issue in early C++ template metaprogramming. You couldn't give good names to some of your constraints so the errors were nightmares.

I resisted joining a startup that exited for 8-figures because one of the devs was emotional/blame-oriented and another one of the devs, a female, was too into me.

1) She didn't know what MD5 was. Had never heard of it. 2) He attended a meeting, seemed to keep up then emailed notes talking about 'Jason encoding'.

I thought these are pretty general concepts to anyone even in passing, you should probably know they exist at least? But maybe I'm in a bubble.

Heck I know what it is and I've only used it a few times outside of copy/pasting stuff w/o needing to think about the underlying details too much.

E.G: I tell beginners to use django, not flask.

Because people usually don't have the skill or knowledge to take proper design decisions. They need something to guide them, otherwise the project architecture will be terribly wrong.

Last year I worked on a flask site were the devs stored the password hashed as unsalted md5. And another one with an API that returned sometimes JSON, sometime plain text. And this year one that, to be deployed, required you to run a build process on the prod server, and defined the upload folder and static media folder as the same.

My take on this is: if you want to go the minimalist route, you need to be very good already.

I think it goes deeper than just not caring.

I too have spent the last 25+ years working as a contract developer and in my earlier years I would say I did care.

However, as time has passed I've come to realize caring can cause tension which then becomes problematic.

In most case people (i.e. higher management, fellow developers etc) really don't like too being reminded that they are doing things wrong.

My current approach is to raise an issue once, raise that same issue a second time but on the third attempt, bite my tongue and just leave it at that.

The same thing goes for when you aren't a contract worker and management has slightly different (but not necessarily invalid) opinions on what the right thing is. Depending on your point of view, that and what you said are exactly the same thing with a different lens applied. That is, the "right thing" as viewed from the angle of engineering best practices may or may not be the same as the "right thing" for getting some product out the door, even if many of us wish it was.

My English still needs work.

I actually care. Especially about people and how they feel at work. In kinda why I do this job: it's so easy to make their day better.

I had no trouble with your original post.

However, in my reply I tried to convey the fact that over time my level of care had diminished.

There was a time when I did care.

However after decades working in this industry I can honestly say my level of caring has been beaten down to a minimum.

My impression was your post was reflective of the start of that process.

Gah. I wish I could rebut this but I’m not sure I can. How does one find work for a tech/IT company that actually embrace quality?

Every single business is full of people who are adequate. From the line staff all the way up to managers. Cynical people call it the peter principle, but it might just be that an average manager is only averagely good at judging who is good at their job and therefore average people are just as likely to get promoted.

Or work in a smaller company.

Google was a superpower in 2001. I started working in Enterprise IT then and people thought that I had miraculous powers.

Today, it's a crutch and almost anywhere you look, people are searching for random stuff to throw on the wall to see what sticks.

(sorry, too cynical... but I'm in the field for more than 20 years)

I suppose you could start your own company but then you will ultimately have to choose to ship and eat or perfect and starve

You don’t just try to solve ALL the problems of the organization, which you were not hired to do.

If you were actually tasked to do that, you would want much more compensation.

I also disagree that the risk of an attack is low. An F500 company is the sort of target that can end up in the sights of many different threat actors.

Halifax never paid the price for badly handling their data after all.

Whatever people talk around here, Reddit or random conference is unheard at these companies.

Most devs just punch cards and are happy to know just enough to get going.

Talking about best practices is a lost battle, unless there is someone from above pushing them.

Because everybody seems to just read past this and think "oh yeah, yeah that is how things are", I'm gonna say it: That is terrible.

I mean, it's your business whatever you decide to do, but I disapprove.

What gave you the idea that it's ever okay to decisively not do the right thing? Especially when the reason is money. Sorry but if your reasoning is "I'm not doing the right thing but that's okay because it is profitable" then you are actively ruining the world. You get no respect from me for that.

I find this line particularly insightful. It was the biggest lesson I learned in my transition from academia to industry. No one cared that my work was correct and on time, they cared that the vendor we used caused us to miss the deadline and because I was in charge of the overall system, it was still my fault. A tough lesson, but a good one.

Very clever :)

okay going to play devil's advocate on this one and say that some error messages could be improved. that's all.

1) Knows how to get people to do things, but doesn't know what needs to be done.

2) Knows exactly what would fix security, but doesn't know how to get people to do those things.

Edit: whoops Equifax, not Experian

Equifax stock has gone up since the 2017 data breach, though because consumers are not customers of Equifax, it's banks and lenders who are not concerned with data they don't control. If hackers had broke into Equifax and changed people's credit scores, the banks might have been a bit more concerned.

The equivalent of a regular person having to give up the coins they found in their couch cushions.

If taking on that risk gives someone a 90% chance at a massive comp boost and a 10% chance at a more negative outcome where they're likely still well compensated, many execs would consider that.

Nothing wrong with recruiting internally per-se, it’s more about the fact that many lacked basic knowledge.

I’m painting with a big brush here, but I’ve seen effects of this throughout my so called career.

- 40 years ago career-paths was opened as cobol programmers. Knowledge was scarce and security was in many ways non-existing.

- 20 years ago guys got shifted to IT because they knew how to fix the printer. Client/server knowledge was scarce and security non-existing.

You breed a segment of IT workers, many which are in ways clueless, but it’s big business. It’s enterprise IT.

Massive breaches, slow to change, and downtime by the buckets. Tickets churning along in “automated” workflows.

Queue the outsourcing strategies!

Might seem a sane choice considering the above - only... it’s difficulty to outsource something you’re not in control of.

This obvious lack of control have led to the ITSM field with it’s CABs, ITILs and other acronyms, all designed to lull everyone into a false sense of security.

I could go on, perhaps write a book. Anyway, I totally agree with what you’re saying, just wanted to share my perspective.

IT Risk (2nd line) is mostly non-IT people that try to convince IT people "what is right". That never works. One of the advantages I have when I work for the 2nd line, is that I've been the 1st line and I know the shit the IT staff have to deal with, and I don't pretent I know better, I do know (((EDIT: I do know exactly what they go through because I've gone through that myself))). And my "risk mitigation advice" is actual, tangible, and with real examples.

There is also the 3rd line (internal audit) that in most orgs they completely miss the mark. ZERO IT knowledge, probably former Big4 that have never seen a console in their lives, wearing a police hat barking orders.

No wonder that the IT landscape is suffering.

I also understand that COO/CEOs don't allow CIO-CTOs the time to have a freeze period, STOP running forward and give them the time to pause, breathe, think, repair. You can't be making and perfecting at the same time. Nobody has the resources for that, so it's all accidents waiting to happen.

I'm not fearmongering, I've just seen enough crap on IT systems (mainly on LARGE corporations) that have made my skin crawl..

“Let’s just buy and implement yet another indispensible enterprise tool and we will _finally_ be in control!”

There’s one thing, and one thing only that allows the speed business want and enable the security and audit required - it’s called automation.

Nothing beats competence coupled with automation.

Let’s use the machines that was invented and built for automation to actually automate stuff! Ok, Enterprise IT?!

Almost every real world security post mortem i have ever seen ends up as untimely application of patches due to the business either rejecting downtime/changes or simply not having the tools and staffing in place to keep up with changing vendor recommendation and security updates.

And despite every evidence based report placing the blame for our current mess on "systematic maintenance failures" the only thing we heer hear from the MBA mills and business leaders is a call for more snakeoil products that can, do what nobody have yet to demonstrate under real world conditions, and add security to an insecure environment.

This is not incompetence/ignorance it's denial likely caused by an "prisoners dilemma" explained elegantly in H.C. Andersen's "The Emperor's New Clothes" where nobody wants to be the first to admit that they aren't keeping up with best practices for fear of ridicule or worse.

A lot of big companies outsource their IT to the cheapest vendor, who, in turn, outsources roles to onshore/offshore. There's not necessarily incompetence by virtue of people from elsewhere in the world, but there is sufficient incompetency, second-stringers and lack of accountability because of all the bureaucratic layers and indirection in the responsibilities. As such, technical debt, confusion and substandard work thrives because of all the vampiric technology "ticks" consulting companies who maximize profit before customer value.

The way-out is for companies to directly hire fewer but better technical employees, employee-ownership and not jumping on the IPO bandwagon because of the perverse motivations of publicly-traded companies.

Example: one of the first questions I try to ask when starting a new job is, "Can I have an accurate list of the physical hosts and the IP of the management NIC?", and the answer is usually some form of, "We don't maintain a list like that, you'll have to grab everything from [pick two]: (DNS|Spreadsheets|Monitoring System|Configuration Management|nmap|ARP tables).". Then, because of course, lists don't match with each other, so literally no source of truth for what hosts exist in a network exists. Even for production! It's truly maddening.

Answer: "The light-ou... what?"

https://en.wikipedia.org/wiki/HP_Integrated_Lights-Out

All of my outsider knowledge indicates that none of the multi-billion dollar organizations can protect themselves from adversaries 1/1000th their size, and I would like to know if this is consistent with the knowledge of people with more direct firsthand experience. Thanks.

At the lowest levels, this is great because there's some very easy and cheap fixes to get large gains in security, but at the high end, each incremental gain increases in cost until it reaches beyond the realm of feasibility.

Air gap all your computers? Cool, you just killed productivity which massively increased costs. Actively supervise every user? There's some niche systems that probably require this level of security, but it's rare. Even then, I don't think such a thing as perfect security exists.

That's not necessarily the point though, in an era of APT. I like to say breaches are inevitable, the real question is how fast do you know about it so you can mitigate/respond? HIDS/NIDS, auditing, monitoring and logging are the core of this imho.

I can think of some reasons why this might be:

- It takes a particular kind of personality to ascend to a C-suite role, and that personality isn't a good fit for solving this particular problem

- Concentrating responsibility for this problem in a single C-suite role lets the rest of the C-suite ignore it as "somebody else's problem"

- Concentrating responsibility for this problem in a single C-suite role serves mostly to provide a handy scapegoat when things inevitably go wrong

- This is a cross-cutting problem that can't effectively be siloed into a single role, even a C-suite one; unless the CEO/board also buy in, the CTO/CIO will lack the authority required to override objections or inaction on the part of other officers

They make the argument that every C suite employee should be tech literate, and if thats the case, then all the "tech decisions" dont fall to one bottleneck on the team, and it isnt that one persons job to persuade everyone else of something they may choose not to understand.

The organizational structure itself, perpetuates silos, and holds companies back from evolving and growing.

"One of the key reasons the C-suite has not yet developed tech maturity is the presence of the CIO. Executives feel that they can deflect technology responsibilities to the CIO in part because the very existence of a technology executive provides an excuse to do so (why else is he or she there?) In the same way that no self-respecting firm would hire a chief quality officer today (quality should be everyone’s job), firms risk perpetuating the technology equivalent of a chief quality officer when they hire a CIO."

"Even if the CIO’s role endures, expect it to involve more facilitation, coordination and strategic planning rather than implementation and operation, while the rest of the executive team handles day-to-day IT decision-making." CIO should own the process of governance building, and collaboration enablement. Figuring out how to facilitate communities within the company coming together, and supplying them with the resources they need to succeed. Just like any other sort of resource planning.

I work for a company that you've definitely heard of, and a lot of people have actively used our product. We're a very big company. We have domain admins browsing the public web via interactive RDP sessions on the domain controllers themselves. That is one of many horror stories of the security at this company.

I'm currently in ops/sysadmin. Large org. Yes, the incompetency you see is sometimes incredulous: I have helped developers install Visual Studio; how to use RDP; had to explain how saving to local disk is different from a networked folder ... I can't think of better examples at the moment, though they exist and are plenteous.

Thing is, I am a hundred percent sure these same people could have turned the tables on me and be aghast by my lack of knowledge in many disciplines.

There are more things to know in this world than any one person can and it is thinking you are beyond this that is truly delusional.

Even with a "verified expert" in a subject, whatever that means, we can find ample holes in their knowledge.

It's the same whether you're in manufacturing, distribution, health care, etc. Yes, you have to be able to learn a bit about the field. But just being a domain expert ("knowing about tech") often does not substantially improve the overall output of the value chain, as experienced engineers learn eventually.

while this is completely true, many people on the 'business side' don't see it this way at all. thankfully this is changing in the culture, but at a glacial pace.

Yup. Left to their own devices, engineers will chose to do what is “coolest” using the hippest technology stack and the most pure architecture imaginable. And they’ll build something and it will be cool.. to them.... but it won’t solve any business needs or will solve the wrong ones and not deliver as much value as it could have if it had somebody with a good business head on.

...or they’ll go reinventing the wheel and build massive costly systems that should have been purchased off the shelf from a vendor.

Nope. You need a balance. It isn’t enough to just have tech smarts. You need somebody with business smarts to keep things grounded and solving real business problems that deliver value to the customer.