Cynicism and Experience | Hacker News Reader

Cynicism and Experience

jamisondance.com

45 pointsyitchelle27 comments

After working for about 8 years at 2 different companies, I started a new job. When I came on board I found the dev team to be highly dysfunctional, and repeating a lot of mistakes I'd spent the past few years working through. An example is: using Java Hibernat/JPA ORM to build intricate object hierarchies that resulted in massive amounts of data loaded at runtime, causing out of memory exceptions and constant gc pauses. On a 32 bit jvm you only get something 1.5GB of usable heap (even if the jvm/os allow you allocate more), when a user logs on and 500MB of data is loaded, well, you can only accommade 3 concurrent users.

So I went in, tried to communicate this, and talked about at my previous job we had used views and stored procedures to not load the entire object graph when only a subset was needed. Crickets. No one cared.

It was very disheartening. Really made me doubt myself, and my ability to communicate.

You were "the new one" here and wanted to tell people they did something that sucked terribly. Most people don't want to hear that and act accordingly. Not easy at all.

Still, this is the strategy with the best chances. The existing team may be too invested in the current concepts, and as a new member, if you don't speak up early, your possibilities to change something vanish with every day you say nothing.

Can you explain why the new person's influence fades so quickly? The new team member who says "I know how to fix all of your problems" on day one looks like an arrogant jerk.

The team member who starts to fit in and then says to the right people "It looks like our system has a memory management problem. I've got a lot of experience with this type of issue. Can I help out with designing a solution?" is far more likely to get into a constructive dialog and may move things forward.

If the OP wasn't brought in with the goal of saving a project that was in dire straits, then trying to fix what you think are the biggest problems immediately isn't going to go over well.

I think you are pretty much right. As technical as our industry is, we are all humans; emotions, anxiety etc, comes into play when dealing with another person. Approaching it in the right manner will reduce the barrier.

Now imagine that you have 20 years of industry experience.

You can't step on people's toes, and organizational cruft doesn't go away overnight. If changing their culture is an ambition you take seriously, it's going to take you a few years, and you'll be a manager at the end of those years. Because changing culture is a job for a manager, not a team mate.

I can't tell if you're blaming the technology stack or just how they were using it. I've been writing large-scale webapps using Hibernate (then Hibernate 2, then JPA) for over 12 years and there are right ways and wrong ways to do it.

People usually don't care about someone else's experience and want to make the mistakes by themselves. So there is no point in explaining.

TL;DR: 1. Please communicate in precise & constructive manner. 2. Do not generalize your experiences. 3. Some cute pictures of small animals.

You forgot the first part: Don't be cynical

Typical YC post, sad

i think your wit is being underappreciated. i lol'd if it's any consolation

I absolutely agree. This is usually a first sign for me to back away from a conversation when someone I just met "blindly" defends or rants about a technology without laying a valid argument.

Also +1 for the puppy break :)

I have to jump in and point out that there are things that are objectively good and objectively bad.

Well, let me first say that nothing (except, perhaps, breathing) is objectively good under all use cases. Haskell is objectively good for the level of code quality that it makes possible, for the beauty of language, etc., but you wouldn't (to my knowledge) use it for a hard real-time problem with sub-millisecond latency deadlines. In terms of specific tools and languages, there are few things that are objectively good and bad in all circumstances. Even tools that I personally dislike exist for a reason, and it takes some work and insight to know what that reason is (and, then, gain a begrudging respect for the tool).

However, as I get older and observe (in part, by being part of it) software management, I realize that there's a lot of so-called "innovation" in the field that is objectively harmful and with absolutely no redeeming qualities: stack ranking, Scrum, the two-week "sprint" cycle, the idea that it's normal rather than dysfunctional for a team to spend 3-7 hours per week in status meetings, and the willingness of management to jerk people around from one project to another as if they were interchangeable parts, denying the average engineer the experience of actually ever finishing anything. This industry is in advanced catastrophic failure and someone needs to fucking step up and save it.

There are things that objectively suck and of which it is an objective fact that a person who supports them is either misled, stupid, or malevolent. At this point, I'm not talking about technologies because I would never, ever say (because it isn't true) that Java (as much as I dislike that language) is objectively bad for all use cases. For some use cases, it's the exact right tool. On the other hand, software management generates bad ideas by the truckload ("Agile" and Scrum being the current rash of stupidity, along with the open-plan fetishism and age discrimination coming out of the Valley right now) and someone needs to call that shit out because it's ruining a generation of software engineers.

I've come to the conclusion that Sturgeon's Law (90% of everything is crap) is often true, but that's OK so long as there's a filter that allows the other 10% to have disproportionate impact. I like Haskell because the compiler itself acts as a Sturgeon Filter. It beats on you until your program is, quite likely, not-crap. Software engineers, themselves, willingly run their work through Sturgeon Filters (compilers, test suites) all the time because the job requires a respect for how hard and detailed the work is, and an acceptance of one's own fallibility. Software management, on the other hand, has no Sturgeon Filter... because the appropriate filter would be the people being managed, who don't have the power to stand up and say, "All of this neo-Taylorist Scrum nonsense is less than worthless and everyone talented will be gone in 12 months if you actually try to Scrum-ify the whole company." The reason why software engineers have such a low respect for software management is that the latter never gets direct feedback when they fuck up. Programmers get called out by their subordinates (compilers) and like it that way. Managers are rarely directly told that stack-ranking and Scrum are horrible ideas that can kill a company within months.

On an aside, how did cynicism become a bad thing? For all the negativity attached to the word, its original definition was something related but fundamentally different. Originally, to be cynical meant to do the right thing in spite of a knowing detestation for human political machinations and moral weakness. Cynics valued simplicity, clarity of knowledge, a lack of personal shame, and reserved (but direct) compassionate action. How is that a bad thing?

Scrum has a place, like anything else, and is not objectively bad, as much as you may dislike the principle. There are plenty of people who are neither misled, stupid, or malevolent, who like scrum and apply it where it is appropriate, which is not everywhere.

Trust is a two-way street. Not all engineers have low respect for managers and vice-versa. Many of us have regular discussions which effect real change at our organizations, discussions built on mutual trust and devoid of kneejerk reactions to SDLC philosophies or management styles.

Spending 5 hours per week or more in status meetings, except as a temporary arrangement in an emergency, is objectively bad.

The idea that engineers are only allowed to work on items in the backlog is objectively bad. Sometimes, it's better to just work rather than trying to politick your work item onto some "backlog" and then work on it.

The implied interchangeability of engineers that comes along with Scrum is objectively bad.

A policy of permanent, aggressive visibility into day-to-day fluctuations of an engineer's work is objectively bad. It's also discriminatory (people with health issues may have acceptable or even excellent average productivity, but high day-to-day or "sprint"-to-"sprint" variance) and counter-productive (since the best people also have the most day-to-day variance). Again, that day-to-day focus is appropriate for an emergency, but not as a persisting policy.

The focus on two-week "sprints" with no thought or allowance given to design, to R&D, to code cleanup and maintenance, to individual career development, or to long-term progress in general, is objectively bad.

The idea that engineers should go to work on Monday having no idea what they're going to be working on for that week, and having no say in the matter, thus obliterating long-term focus as even a remote possibility, is objectively bad.

The implicit age discrimination that comes out of a culture of permanent juniority (there simply is no place for a senior engineer on a Scrum team) is objectively bad.

The dishonest way in which this "Agile" nonsense is sold-- first, in comparison to a ridiculous straw man called "waterfall"; second, as a sustainable management style when it actually works only in short-term emergencies for up to about 6 weeks-- is objectively bad. See this Quora answer for the history of Agile and why the sale of it is so often dishonest: http://www.quora.com/Why-do-some-developers-at-strong-compan...

"Scrum" is just a way to package micromanagement (neo-Taylorism) with a macho sports metaphor that makes it hipster-compliant. Nothing more.

Well said. This is exactly why I hate Agile/Scrum, but you expressed it better than I ever could.

All of the things you're describing are attributable to bad implementation of the basic idea that building software is not like building physical machines.

Scrum, or any other agile SDLC, can do the things you describe above. It can also do none of them.

I think most experience is not transferable. Most people are too dogmatic and lazy. Signal to noise ratio is very low , and unusual ideas simply get discarted by spam filters in our brains. I will give two examples:

I use 5 years old HP laptop, most people call it 'the brick'. Newer laptop would reduce weight I carry by one pound, but has several disadvantages:

- no easy way to swap ssd between desktop and laptop when I do travel. With my current setup it takes 2 minutes and OS restart.

- even newest laptops have the same performance and only 8 GB memory

- IDE and unit tests kills battery life, even newest machine lasts only a few hours under modest load. No improved battery life from new CPUs. Replacement batteries are must.

- it costs peanuts, I can take ssd with me and leave heavy laptop at hotel room

- because its cheap it can take a lot of abuse. Expensive components (batteries, ram, ssd) can be transfered to replacement laptop.

Second example is way more controversial. I criticize over-vaccination. For most people it means I am conspiracy nutjobs, but in reality my country (Czech Republic) has 3x more vaccines than Germany a few kilometers away. There is simply no opposition to medical industry. Even our doctors are now refusing to get vaccinated. (my children have all shots recommended by EU)

> - no easy way to swap ssd between desktop and laptop when I do travel. With my current setup it takes 2 minutes and OS restart.

Could you share your setup and OS ?

Linux and any laptop with removable DVD rom (extension bay). In my case elitebook 2540p with i7 CPU

You are booting your OS from the SSD right ? If so, which Linux flavor are you using and did you have to tweak the kernel, drivers or anything like that to get it working ?

Are you using the same laptops and desktops ? Am I right to suppose you sometimes have to set up the BIOS so it boots on your HDD or does it somehow automagically work ?

Kubuntu 14.04 64bit with no tweaks. I just selected boot disk in bios a few years ago. No magic, no problems.

Most Linux can do that. Even Windows (at least Vista and laters) are able to work on two different PCs almost without teaks.

What happens if I plug my win7 main SSD into another friend's secondary SATA port (the one in the disc bay of a laptop for instance) ? Does the BIOS/(U)EFI act as bootloader ? If not: does the original win7 detects another win7 on a different partition and then triggers a bootloader ? If no bootloader are involved, what mechanism is in place to detect the other bootable disc ? It's all BIOS boot menu ?

(replace win7 with any linux)

I'm not sure what happens if there another disk with Windows (also I've never tried with UEFI). I think that changin boot disk at BIOS should be enough. At worst you will see black screen/BSOD, but your system will be perfectly fine, so you can plug it back to your computer. If you succeded probably you would need to install some missing drivers.

Linux are more flexible. Few (about 10?) years ago I had to change xorg GPU driver manually, but today autodetection is much better.

Reply on news.ycombinator.com