anti-social means that a person does not conform with what authority says.

"authority" has an opinion on religion, good manners, social interaction, biodiversity, climate change, whales hunting, and every possible topic on earth.

People can choose to fight the authority at any level they want on any topic they want.

Two people can fight authority on different topics, both of them see each other as anti-social; but both of them are anti-authority.

"Choose your weapons, your enemy has been chosen long ago, even before you realized." -- anonymous

"anti-social means that a person does not conform with what authority says."

Simply incorrect, both etymologically and logically. Authority is hierarchical; society is peer to peer. Authority is hard power; society is soft. When you're anti-authoritarian you're defying hierarchy and force. When you're anti-social you're just being a jerk to your neighbors. Not the same thing at all.

I think that //avoiding// could be considered by the authority as a disruptive disorder.

Authority want you to follow instructions, to do the things in their way. "They are the guardias of the truth" but if you found a way to do your best where authority isn't an obstacle, it also show new ways to improve the world you live in.

Open new ways of doing the things to others.

Perhaps we should consider that Programmers its a super class of Scientist, Engineer, Designer, Technician.

And that not everybody should know everything about the subclases.

If you think of yourself as developer(?), and Rick as a mathematician its fine!; the problem comes when Rick think you should behave as a mathematician because you are a programmer or viceversa.

> In the early days programming was considered a subdiscipline of mathematics

But then the Electrical Engineering guys come and conquer, then CS evolve closer to EE than to Math.

And these days, well... your boss always look at you and say that does not want to now about math or performance, he want to know about accomplished deadlines and nice UIs.

IMHO most software 'service life' it's not long enough to justify the annoyance of the accessors.

Most software are outdated after a couple of years.

But I still think that accessors are a must if you know that the software will be immortal (like Internet banking applications)

That's a pretty brutal stance. :|

I can't say I know the average shelf life of a software component in various languages, but I can say that at least things like Java have managed to justify their use of accessors by that metric. Maybe the focus should be on writing less throwaway code than deciding whether to "invest" a few extra minutes or not on accessors.

That is an understatement. I am currently working on a code which was written at 10 years back. And that code is still running on production server.

tl;dr; Usually enterprise Java applications does have long "service life".

I think most companies have tons of legacy code that is stilly lying around and in production use. When I was at Dreamworks Animation, we were still using tools written back in the 1980s to create animated features; albeit we kept improving on it whenever it didn't fit the bill.

"""Most software are outdated after a couple of years."""

You'd be surprised. Tons of code runs in production, even in the latest of shiny systems, that was written 10 and 20 and 30 years ago -- either in whole or in parts, refactored etc.

From 1986's NeXT OS that is now OS X Lion and iOS 5, to Bill Joy's TCP/IP, to Emacs.

And tons of enterprise/banking/financial/military systems use ancient code, even 70's COBOL...

For DBA's should be a must, for automation purposes, backups, custom reports, etc, etc...

And for Marketing it's just kind of scary... some of those guys start by saying: "I know how to program and that feature could be ready in a day or a couple of hours"

I work in marketing->e-commerce and I think it's a great idea to learn to "program". By no means am I a good developer, but I have played enough with Rails and PHP and deployed a couple of simple apps to production environments and I feel like I know enough to understand how to put together a coherent business requirements document.

I think if not programming, at least process modeling or class diagrams should be learned.

> I think it's a great idea to learn to "program".

Believed or not I'm completely agree with you, learn to program will definitely improve the way you work.

But sometimes, some guys with little involvement in a project that know "how to program" cause more damage than good.

This type of conversation begs the "put-up or shut-up answer" and if it works you get a new feature. the real trick is actually dealing with long-term support for something that might have started out as a hack. Features and short-term tests usually need to be refactored for long-term health. If you don't do the work up front be prepared to do a bit later, just make the choice consciously.

NOnononononono.

If it "works" superficially it will be considered good enough by management. High fives all around, the checklist is ticked off, and everybody moves on -- except for the poor developers have to maintain the mess.

Nimbleness doesn't mean creating crushing technical debt that has to be solved immediately by somebody else. :)

Farming "Just manual labor"?

Common, have you ever tried to plant something?

THAT is difficult!

Any profession could become a mass profession.

I also learn to be a programmer with languages like Scheme or Prolog (never really use those outside the classroom).

This experience give you a broader view of the possible solutions to a given problem, let's say it give you a complete toolbox rather than just a hammer.