
Cynicism and Experience - yitchelle
http://jamisondance.com/03-29-2015/cynicism-and-experience
======
marktangotango
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.

~~~
mkesper
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.

~~~
vog
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.

~~~
otherdave
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.

~~~
yitchelle
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.

------
mariusz79
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.

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

~~~
benihana
You forgot the first part: Don't be cynical

------
grgssrv
Typical YC post, sad

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

------
peshkira
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 :)

------
michaelochurch
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?

~~~
mmoche
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.

~~~
michaelochurch
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...](http://www.quora.com/Why-do-some-developers-at-strong-companies-
like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church)

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

~~~
mmoche
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.

------
jkot
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)

~~~
johnchristopher
> \- 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 ?

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

~~~
johnchristopher
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 ?

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

~~~
johnchristopher
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)

~~~
szatkus
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.

