The "Our Values" table? That's getting framed and put on my wall.

I read it and am saddened by how much happier I used to be. It all used to be so much more fun.

Frameworks are all about "magic" plumbing that shuttles your data from one place to the next in a completely obscure way. All in the interest of saving you time. Of course, it ain't free, it's paid for by all the extra cruft put in place to make it all happen.

Agile is responsible for a lot of it. When you have interchangeable developers instead of people that focus on what suits them best, all of a sudden you need tools to that even the weakest database guy can get his database tasks done. Agile never fixed the mistrust between stakeholder and developer, it just tied the developer's hands. Terms like "polish the cannonball" are used to beat down and suppress the desire to do things beautifully and just turn software development into a machine in and of itself.

On today's episode of "do my homework for me". Half surprised it got so many answers, but it is Stack Overflow after all, where everyone is eager to show how much smarter they are than everyone else.

To follow, git's popularity is clearly based on the velocity from it's use for the Linux source, not because it's particularly better than any of the alternatives. Kind of how TFS's popularity is based on the velocity of Visual Studio users and being treated like a 1st-class source control system instead of leaky 2nd-class plugins for SVN and others.

That attitude you speak of is definitely Linux culture. You can occasionally find that kind of arrogance in Windows, but not nearly close to those legendary proportions.

Universities also teach "Women's Studies", so, the curriculum is no benchmark for the quality of anything.

Thanks for the recommendation with Vector. Manual memory management is kind of a pain (and, honestly, if I'm going to explicitly allocate and deallocate, I'm probably going C), but automatic memory management isn't really a requirement of OOP. Polymorphism is, and if you're using the C++ runtime, you're using it! That said, I'd be lying if said I never saw someone use printf inside C++...

C++ isn't without it's problems but overcoming those problems can help with pretty much anything, whereas learning to overcome Java's problems only really help for Java.

Heh heh... "the JVM". I've seen stuff inside my org fail because not only did someone not use a very specific version of the JVM but also used the wrong brand (Oracle vs IBM).

Do you want the old man with bad teeth because half have fallen out or the old man with bad teeth because they're all a lovely shade of green?

I don't disagree with your consideration of "hobby languages" per se, but learning Erlang has definitely upped my game in doing high(-er) performance multithreaded stuff in C# which I do get paid for.

I was very careful to say IL, not CLI.

There are no .NET languages compiled into IL that are not OO.

Agreed. OOP is useful, so if you're going to go for it, go C++ (real C++ not just C in a C++ wrapping) or .NET. .NET took everything good about Java and left behind (mostly) everything bad about it.

Oops!

My excuse: users never read the documentation!

I'm curious, exactly how many sites out there have a 128x128 favicon?

Scrum and Agile are not about software development, it's about cultivating the mistrust between developer and stakeholder. Companies profit off that mistrust by selling training materials to organizations and certifications to people wholly unsuited for application development (Scrummaster? Please. Get a real job.)

It promotes a commoditization of developers by pretending they're interchangeable and all equally qualified of doing all tasks, denies that good development work has basis in creativity and artistry, and has directly led to lowest-bidder offshoring and H1Bs. Burndown charts and other metrics are used as an invitation to micromanage by showing how sausage is made.

It comforts stakeholders into thinking it's ok not to know what you want, instead of demanding rigorous thinking about business process and how that translates to technical process. It shunts responsibility of bad design resulting from bad requirements onto the people that were the least responsible for those requirements. Just like matter cannot be created or destroyed, making changes doesn't suddenly stop taking time because the decisions weren't firm to begin with. Addressing failures in an agile fashion only sends the signal to stakeholders that mistakes are a-ok and therefore encourages them.

Agile was hailed as a savior to development compared to Waterfall, but Waterfall as presented by Agile aficionados is a strawman. Developers were never hidden away from stakeholders during the development process, certain aspects of a particular design are engineered to be flexible if deemed likely to change (compare with "you aren't going to need it" from today). Older development simply demands that requirements exist and people that know what they're doing assemble them. It certainly never was a one-way street, and mistakes got caught and addressed all the time without having to wait until the end of initial development.

The only defense Agile has against criticism is "then you're not doing Agile correctly." It's a methodology, therefore, that only works when 100% of the participants are 100% perfect 100% of the time: except for the stakeholders, who have no obligation to do anything correctly. Know what? I can't fly either, but no one would accuse me of not flapping my arms correctly.

There's no need to be afraid of security vulnerabilities in .NET or IIS any more than you need to be afraid of security vulnerabilities on a LAMP stack. Not because Microsoft is just as safe, but because everything is compromised.

Security is a multi-tiered thing anyway. Solid code won't do much if your admin doesn't have a sensible configuration on the machines, just like crap code can hack around safeguards.

Your biggest worry, IMO, is how it will scale. Odds are your implementation won't get popular: in a world where everyone is doing "feature, but in language!", that's the reality of it. Especially without a killer feature (hint: "runs on Microsoft platforms" is not one of those). Lack of notoriety will shield you from, uh, "unrequested penetration testing." If it does get popular, however, and finds it's way into a site even half of what 4chan pulls each day, I would expect you to have to come up with some really interesting paradigms to counteract the weight of entity framework. Consider that any software that runs on sites in the Alexa top 100 would be using exotic enterprise stuff you just wouldn't be able to predict in advance, even if you do read every single Google whitepaper.

Bootcamps are just advertising for the latest and greatest leaky shitty abstraction that won't be supported in 3 years. Advertising that attendees pay for (well, their companies) and they get to use it to expense a vacation.

I don't even understand how duplicates are really a problem. A duplicate question means A) the original question and discussion is missing keywords people might be using to search or understand (a COM newbie might run into COM apartment threading issues and not know how to describe it properly) and B) the original question's answers may be incomplete.

If the search index and tagging system is unable to find the best version of a particular question, that's not the duplicate's problem, that's the site's problem.

Could be worse, you could have been forced to use Yammer

Agile is what makes this possible. "Planning? That's not Agile!" "Thinking requirements ahead of time? That's not Agile!"

So you get stakeholders handwaving their requirements "Yeah, I wanna do xyz with a computer" with absolutely no thought to the process of what xyz should be. You can't plan timelines on that, so of course it's wrong and management does what management does and starts demanding 60+ hour work weeks with weekends. Overworked death-marches aren't Agile, either, but that part is conveniently ignored.

When I was growing up, what pushed me to assembly over the built in BASIC on my machine was speed, like your peer used to do impressive stuff. Making that jump opened my eyes really wide to how a machine actually works and not only did I pick up some neat stuff for assembly but overall it made me a much better programmer even in the higher languages of today.

It's kind of bittersweet that computers today have so much horsepower that novice programmers can get away with pretty much anything they can dream up implemented in all sorts of naive and unoptimized ways.

And another. I guess it's time to dust off the old resume.

Contributor Code of Conduct

I'm laughing already.

Oh, substring search in Language A is 0-indexed, and Language B is 1-indexed. Your implementation in Language B is WRONG! HA! GOTCHA! Where's my big red "REJECTED" stamp so I can slam it on your resume? Obviously you bring no value here at Megacorp.

It's a test that also selects for the company. They obviously don't want people with problem solving skills, they want people with rote memorization skills. Even if you pass a trapped test like this, it's not a place anyone with any kind of creativity would ever want to work since you know what your coworkers will be like.

I wonder if oil rig worker applicants are similarly tested on being able to operate heavy machinery in pitch black darkness while wearing boxing gloves...

But then the feature flags themselves are technical debt. You'll have to come back later and whack the flags and the old stuff if you want to have clean, supportable code. Otherwise you leave huge swaths of code and comparisons that never change laying around to misdirect anyone trying to wrap their head around it.

That's because Scrum is a software development paradigm that doesn't say anything about programming! It caters to the needs middle-management and Project Managers, not programmers.

Scrum comes from Rugby, a sport that, strangely enough, sounds like another word for something rather unpleasant.

"That's because you're not doing Agile correctly!"

Any time I hear that I want to punch them in the face.

Required reading. https://www.aaron-gray.com/a-criticism-of-scrum/

Not much you can do if you're looking for a steady job and see nothing but Scrum everywhere (other than go freelance, but, hey, that's not for everyone), but at least you can form a resistance from the inside.

"It's better," the evangelist would say, "because with Waterfall you're determining requirements when you know the least about the project." It's absolute bunk. If requirements are bad it's because no one is paying attention to really visualizing how everything fits together. But rapid development is a great way to just say "get it done" and take none of the blame when people with no direction do what people with no direction tend to do.

On an aside, Scrum is a giant con. They took Agile and renamed a bunch of crap, Then they make people pay money for certifications to create and justify a do-nothing 6-figure job (scrum master). Then take over conventions like a virus with "you mean you're not doing Scrum?"

The people with real skill feel pressure to compete with these laggards and start to cut corners to get paid. Then you have a few billion Indians mastering the art of selling garbage for cheap, and a few million Americans mastering the art of selling Indian garbage with an American face.

Oh boy does that ever hit close to home. We've got different units in our company that do development, and some units are strutting around that they get their projects done at 60% of the cost and in 75% of the time. Meanwhile the support groups are shared, so the support costs on trash from India and South America - that are easily double compared to the in-house devs -- are effectively hidden. Of course these outsourcing firms have slick full page ads in Fortune dead-tree magazine,

And I'm sure all of you have seen Programming Sucks, but if not, here it is. The two are separated by two years but if you ignore the dates they seem very interconnected.