
The Hacker Ethic - Harming Developers? - Anon84
http://radar.oreilly.com/2009/07/the-hacker-ethic---is-it-harmi.html
======
tsally
Well written code is approchable without constructs like UML. The problem with
most 'programmers' is that they don't think they should be doing hard
programming each day, every day. Yes, experienced hackers make it look easy,
but it took them a lot of work to get there.

Also, just because hackers are a scare resource doesn't mean we should accept
a lower quality in the end product. What if we did that with the engineers
that worked on airplanes? Software is used in many similarly critical
situations. It's time to accept that the things that adults use like UML and
overly complex IDEs don't increase the number of good programmers. Ironically,
they actually mask the true ability of a programmer. To actually accomplish
that, you need to start with the programming curriculum in high school and
early college education.

~~~
mahmud
<rant>

 _Well written code is approchable without constructs like UML._

ANY code is approachable without constructs like UML. Compare the Addison
Wesley "Professional Programming" series (the ones that published APUE, UNP,
Pthreads books, etc; the white text with a splash of blue) to the yellow/khaki
"Object Series", the ones that published Booch's books and the french dude who
was pushing Eiffel, etc.) The difference between the two series of books is
essentially UML and "object technology". The first is readable bliss, the
later is an abomination cast at us from the bowels of hell.

UML is wankery. It's what liars and crooks push when they lack the sufficient
bullshit to make it to high executive positions, and the talent, dedication
and honesty necessary to be an engineer. Everytime I met a "software
architect" that used that garbage, the person was always nearly clueless and a
pain to be with.

</rant>

~~~
hello_moto
And should we be amazed at your drawing scribbles, boxes, triangles and
whatnot? How should I interpret your abstract and masterful artsy drawing?

There's a time and place for UML. Overdoing is wrong, I agree. But that
doesn't mean UML is bad. When a project is huge enough, sometime you do need
few pictures to help others to understand the big picture. Some people can
understand better via visualization.

~~~
sofal
I'm not sure if others feel this way, but I'd actually rather see someone's
free form artsy drawing than a UML picture. I think it's reasonable to expect
that a skilled developer should be able to provide an intuitive whiteboard
diagram or slide-show graphic. It takes some practice, sure, but I think UML
is the wrong solution. UML is constantly misused. Big enterprises love CASE
tools like Rational Rose, which push UML way beyond its intended usefulness.

~~~
gruseom
_I'd actually rather see someone's free form artsy drawing than a UML picture_

I totally agree. The whole idea behind UML is to force diagrams into a set of
constraints drawn from a particular model of computing and design (early 90s
OO, I suppose) on the assumption that this is the "right" way to imagine
software. This excludes the ineffable creativity which drawings are so good
for. It's amazing what happens in a good design discussion when people
spontaneously pick up a pen at a whiteboard _without thinking about it_. UML
forces people to think about something other than the problem at hand,
distorting ideas and breaking flow.

And in the name of what? "We need a standard," they used to say, "so that
people know whether they should draw square boxes or round ones, so we can get
beyond the notation wars." What tripe.

------
jasongullickson
Spot on:

"This entire debacle is representative of a problem I think is endemic in the
industry these days, the inability or unwillingness to engage in rapid
prototyping. Every successful project I've ever worked on (and I've worked on
some fairly large enterprise-sized projects), we started by designing and
coding a quick "throw-away" skeleton of the application, that let us look at
how the thing worked, where the unseen warts were, and where the vendors had
lied about their APIs, etc."

I don't have the perfect solution (yet) but there is a definite difference, a
sort of "feeling of entitlement" present in many coders who came along after
the microcomputer wars of the 1980's.

They expect things to "work as advertised"...and a heartbroken when their
project ships late due to unexpected difficulties with the
environment/ide/framework/etc.

~~~
edw519
"Every successful project I've ever worked on (and I've worked on some fairly
large enterprise-sized projects), we started by designing and coding a quick
"throw-away" skeleton of the application..."

Me too. But for another reason...

I almost never get real specs. But once a user sees a prototype, they are
suddenly no longer bashful. They'll tell you how it really should be.

~~~
omouse
Someone on Slashdot commented and said that they're company has 2 phases for
developing software. The initial prototype phase where the hackers get to use
whatever tools they need to write the software, just to get something out
there. The point is to figure out the specs based on that and then once they
do that, once they have the scope of the software determined, then they can
just write a spec and feature list out and hand it over to the engineers who
turn the prototype into an actual product (with documentation, full-scale test
suites, etc.)

------
CodeMage
Nayar is actually right, in a way. Hackers _should_ be considered unemployable
by companies like HCL. From what I know of shops like that -- and I've
interacted with various over the years -- a hacker would be profoundly unhappy
working there.

------
edw519
"The India shops _love_ methodologies like UML and the like, specifically
because the problems have been reduced to a simplistic enough granularity that
they can be doled out to junior-level staff, who may have only been onboard a
few weeks because of the massive churn over there."

Let's tell it like it really is...

The India shops (and many U.S. shops, too) love methodologies like UML because
they make someone who does not know what he is doing _appear as if he did_.

This is especially important for maintaining margins above 50%.

~~~
erlanger
This is the most recent comment from the article that started this little
discussion:

> Hi All,

> I am just another IT Engineer from India working for the one of the largest
> IT companies in India. And I know that what Indian IT companies like HCL
> work for, only money (through offshoring). They do not want people who use
> brain because they don't have such work to do. All they want is a duffer who
> sits on a desk and can work like a donkey for 12 hours a day. There are no
> excuses such as work life balance etc, because client is the boss. You can
> not say no to anything. They fake the resumes of employees, make them
> achieve impossible target by making them work like a dog. The estimation is
> the beginning of a big mess to happen. Moreover an IT engineer must be
> prepared to be fired, because they have a reason of recession. They can
> handout dividend to shareholders by cutting the variable pays.

> As per what Veenit says is Indian people learn to following processes etc,
> but when you look inside a IT company, you can rest assured everything can
> be managed. There is not advantage in following processes, because what I
> have seen is 90% time of my PL goes in following these processes. The
> project leader has no time for his team.

> I believe that IT companies like HCL wont take up innovative work at all, so
> creative minds in US should not bother about his comments. Although lots of
> work is getting outsourced. The core work is going to remain in countries
> like US, because most of the people working in huge companies like HCL,
> Infy, TCS ,Wipro and Satyam become incompetent because of the quality of
> work they get most of the time.

> Moreover a person wont work on a specific business or technical domain,
> which leaves makes you loose confidence.

> There are many people like me who once get stuck in such companies, its
> really hard to come out.

> So Americans, better dont go to such sh __companies. Its better for your own
> future.

Interesting.

~~~
emontero1
As someone who's worked closely with Indian developers for the past 3 years, I
can corroborate several of the statements above. My teammates and I were
usually spellbound by the acronym-laden resumes of some Indian developers.
"Wow, this guy must be really good! Look at his credentials, dude!", I used to
say frequently. Reality, however, sinks in rather quickly. More often than
not, the "super star" ended up turning in subpar code, working a bazillion
hours a week and, still, missing deadlines and estimates by ample marks. It
was all very confusing at first. I understand fully now.

I'm not saying there aren't excellent Indian developers. I've also met a few
of those. Alas, those are _not_ the majority.

~~~
sophacles
Im too young to know firsthand, but I recall during the .com boom here in the
states one of the problems was that anyone who knew how to spell html could
get a programming job. It was a hot field and people seeking the "big money"
were getting programming jobs they didn't deserve. On the university side I
knew several people who switched majors to business when they learned that
coding involved typing (no joke). Perhaps the same is going on in India right
now? From all accounts, programming is the hot job in India.

I bet if someone put together a good summary of the "brilliant" people in a
field, and had them talk about the level of talent when that field is the hot
job, it would look the same as these coder stories.

~~~
netsp
Maybe this implies that the current state of the Indian market is temporary.

------
pingswept
I hereby resolve continue to learn less of "business processes" and "best
practices."

If I'm lucky, I will entirely disqualify myself for jobs as a "programmer."

~~~
lallysingh
No no no, just remember where to look. HN's ideas of business processes and
best practices are quite different from what you see in body shops like that.

------
gaius
It doesn't help that the link to "stupid hacker tricks" in the referenced
article is about script kiddies.

------
rbanffy
There are programmers and there are hackers. To use an interesting quote, it's
a privilege, not a right.

~~~
jimfl
"There are programmers and there are hackers."

Then there are software developers.

Software developers are sometimes called upon to program, sometimes hack. A
lot of what a software developer spends time doing is neither, working closely
with all the other roles in a development shop to deliver software. Working
with business owners, architects, junior devs, documentation, QA, operations,
support, and the users requires a lot of time spent not programming and not
hacking.

~~~
omouse
But remember not to fall into the trap of thinking of yourself as an engineer.
Two different fields entirely and what may work in one field, may not work in
the other field.

Engineers deal with physical products and fully-specified tech specs and all
sorts of extra business stuff that is just a hindrance to a software developer
(or are impossible to implement, like a full tech spec, all software has a
creative component that's hard to control).

~~~
jimfl
Indeed. I avoided the term engineer purposely.

------
rjurney
Yes, having machine intuition, mad skills and a deep understanding of how to
build things makes it hard on Indian typists that have to keep up.

Boo Hoo.

