Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Am I the only one here who mostly agrees with the article? Especially with the bad parts. I don't have that much experience, but it's already been over 10 years of programming, freelancing and occasional managing, and I find pretty much everything in this article familiar. From the difference between a programmer and an analyst, the average intelligence level, to the lazynes and lack of motivation which are almost a professional disease among programmers.

If I were employed in a corporation I'd actually _like_ my manager to try and make my work motivating, even though it is fundamentally about "sorting files and making raports". Ignoring the problem won't make it go away.

edit: I'm not one of the star programmers btw. I had to pass 30 to realize I'm actually not that bright, and if I want to make something I have to deal with my lazyness and work and learn.



Yes, though the author's tone was pompous at times, much of this also resonated with me, if (as someone else posted) you put this in the context of a typical corporate IT shop.

He's pretty clearly not writing about a start-up that revolves around software development. He's talking about companies where IT is a necessary cost, very much like the accounting department.


All the management tips in that article make perfect sense:

"Be leery of programmers that are pseudo-intellectual. They are probably hiding something."

If you can't explain something clearly and concisely, you either need to improve your communication skills or really are hiding something (http://www.reddit.com/r/IAmA/comments/9sfm5/i_am_a_man_in_hi...)

"Improve communications within the programming staff by developing a standard glossary of terms. This will also be useful to outsiders who have to interface with programmers."

This is the core idea behind Domain-Driven Design.

"Carefully scrutinize technical proposals. Make the programmers justify it from a business perspective."

ROI ROI ROI

"Adopt standards for documenting programs (e.g., graphics and/or text detailing the organization and logic of the program)."

Duh.

"Develop standard development practices emphasizing quality and program re-usability. Demanding precision in development will result in superior performance."

Duh x 2

"Implement a skills inventory to monitor the talents and proficiencies of the programming staff. This is used to determine the need for additional training, as well to select the most suitable individual for a programming assignment."

If only more managers did this!!

"Promote a program of on-going education, such as a training curriculum, the development of technical library, participation in professional associations, and technical certification programs."

How can you say the author of the article looks down on programmers? Again, most coders wish their organization had a program like this.

"Develop security measures to safeguard the company's intellectual property."

This one is agreeable on some level, however that level is CIO and not team managers.

"Recognize outstanding achievement even for the smallest of jobs."

Ok. You need to recognize people's effort and achievements.

"Manage from the bottom-up. Delegate responsibility and hold people accountable for their actions. Teach employees to supervise themselves."

Of course, the author really does think programmers are morons! How else can he recommend something like this?


I think the issue most people have with this is the stark management/worker divide, in which managers are omniscient and a worker's greatest virtue is obedience.

In a modern organization, I don't feel that my manager is superior to me (especially not in a traditional class sense). We are two professionals with broadly equivalent educations and social backgrounds with slightly different job descriptions, I do more code, he does more meetings. His job is not to tell me what to do, it's to handle the planning and logistics of us jointly working towards the organization's goal, just as mine is to handle the technical and operational side.

And I don't feel subservient to the company either. We are two economic entities collaborating for mutual benefit. If either us doesn't like this arrangement anymore, we can dissolve it with no hard feelings.

In short, this dude's ideas are stuck somewhere near the beginning of his career. He's learnt nothing in those 30 years. It's not experience if you aren't learning from it. It's just paper pushing.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: