• [Repost] The 14 characters you meet as a coder


    Developers often think of themselves as the only sane person in the room. This, as you may know, is also a trait of the clinically insane.

    Left unchecked, certain developer personality types can sink your project -- or, worse, make themselves no fun to work with. In my long and storied career, I've personally encountered all 14 of these personality types. In fact, I have beenseveral of these people to some degree or another; I've also knowingly hired them. You know who you are.

    [ InfoWorld salutes the dev-olution of 19 generations of computer programmers. | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]

    The Developer Diva. Great software is rarely a one-person effort. There are users, plus the testers, plus the crew who markets or sells the work. But the Developer Diva recognizes those efforts in the same way actors who win Oscars thank the "little people." Developer Divas are not satisfied with standard accommodations; they need to be pampered. In fact, someone in management needs to devote at least 50 percent of his or her time to listen to the diva's complaints and get the diva to produce. If that management load increases every time the Developer Diva acquires a new skill, perhaps it's time to send the diva packing, even if the replacement is a little less skilled.

    The Rock Star. Generally this guy knows HTML and JavaScript or maybe PHP, but from the ego you'd think he just set down his Les Paul after headlining at Madison Square Garden. After his 15 minutes are up, the crashing ego isn't pretty.

    The Reluctant Programmer. Rather than urge their kids to be doctors or lawyers, some parents push their progeny to go into software development. Sometimes it works out. And sometimes the poor, benighted offspring gaze out of the office window yearning for hard labor in the 95-degree heat -- anything except spending their lives doing something they don't want to do, whether or not they have the aptitude for it. Usually their work is mediocre, and they're out the door every day at 4:55 p.m. sharp.

    The Holy Priest. This person revels in technology for its own sake and has no patience for the hapless techno weenies who don't spend their days chanting arcane invocations using terms like "regex," "SOAP," "asynchronous messaging," "n-tier architecture," and "CORBA." Holy Priests recognize opinions as valid only if they come from fellow clerics, and they express contempt for "lusers" at every opportunity. They may be brilliant coders, but keep them locked in the closet, far away from customers.

    The Process Guru. You might wonder who would spend all their time reading books on the latest development methodologies. That would be the Process Guru, who knows more about Scrum, XP, RUP, Crystal, PSP, TSP, and COCOMO than the rest of your organization put together. The guru is interested only in the process of creating software and cares nothing about the output of said process. Consuming every minute of every meeting, the Process Guru likes to explain how "we're doing agile wrong" and pontificates about the need for more agile training. Usually, but not always, the Process Guru is recognizable by the Certified Scrum Master status.

    The "Jeopardy" Champion. The expert on arcane trivia, this developer may or may not be generally productive, but stands as the one person on the team who always seems to possess some obscure bit of needed knowledge. Whether it's the details of how "volatile" works in Java, both before and after the changes to the memory model spec, or deep knowledge of tuning a JBoss AS 4.2.3 configuration, the "Jeopardy" Champion is a valuable asset (at least twice a year).

    The Hipster Hacker from Hell. We really need to rewrite all of our software in Haskell because then our code will be beautiful. Never mind the costs! Did I say Haskell? Haskell was so last year. I mean Clojure because it will be simple! Bugs? Features? I have no time for such trivial matters. I have a whole new architecture to write in Ceylon!

    The Architecture Astronaut. This developer loves complexity and never sees a problem too simple to deserve a multitier, distributed system using a Java application server, multiple message queues, SOAP-based Web services with distributed transactions, and native code in C++ for good measure. When not designing byzantine architectures, astronauts immerse themselves in the WS-* specs or CORBA manuals. They may be found associating with Hipster Hackers from Hell, scheming up a new distributed system built in a combination of Erlang, Scala + Akka, Node.js, and Haskell. The astronaut will try to spend at least half of the allocated time for the project drawing UML diagrams and "fleshing out the architecture." Mantra: "The project isn't done until it uses at least 7/8 of the patterns in the GoF book."

    The Insecure Evangelist. This guy/gal designed the entire system, but is threatened by new suggestions from just about anybody. Basically, my ideas are good and yours are bad, unless I repackage them as my ideas.

    The Code Poet. The poet's code is elegant and conforms beautifully to design patterns. On the other hand, the Code Poet holds you up in meetings forever and never notices the missed deadlines or the annoyed looks on other peoples' faces.

    The Cloud Zealot. This character has never heard of (or doesn't believe in) the eight fallacies of distributed computing and couldn't spell "SLA" if you spotted him the "S," "L," and "A." However, they can leap on a trending buzzword like a lion stalking a gazelle on the savannah. The Cloud Zealot races to move everything "to the cloud" with no regard for security, latency, network outages, data interoperability, vendor lock-in, or the long-term viability of the SaaS vendor du jour. Secure in his knowledge that no fly-by-night SaaS offering has ever been hacked, leaking usernames, email addresses, and unencrypted passwords for every user account, the Cloud Zealot sleeps easy. Lucky for him, he'll have moved on to a new company before you discover that all of your employees identities are for sale by the Russian mafia.

    The Traditionalist. "Why would you ever need anything other than Java and an Oracle DB?" "You should definitely run your application on WebSphere." "Oh, you want to send messages between nodes? Let me prepare the XML schema."

    The Uber Traditionalist. This party thinks Java is too newfangled and unproven for production use, preferring to develop on an AS/400, in RPG, using the SEU. The UT spends most of his time regaling you with tales of his youth, when the VAX was still a technological marvel and the PC was yet to be born. He probably built his first computer from raw transistors on a breadboard and never hesitates to remind the Hipster Hacker from Hell (his mortal enemy) that "the ideas in Node.js were originally developed in SNOBOL in the '70s, you know" or "Haskell is just a less pure and inferior LISP in many ways."

    The Proprietary Priest. Telltale signs: Insists that all solutions should use proprietary tools from a trusted name; Perforce, Websphere, AIX, Oracle -- you get the idea. If Microsoft, IBM, or some other corporation didn't write it, then it must be crap.

    If you recognized bits of yourself in the above, you may have enough introspection to avoid totally being one. If you don't think any of it applies to you, then almost certainly the people you work with know exactly which of the above you match.

    Great software is never a solo endeavor. Figuring out that it isn't all about you is probably your first step.

  • 相关阅读:
    gulp基础
    字符串及字符串的方法
    ES5
    JS的设计模式
    VSN与GitHub
    JS闭包函数的概念及函数的继承
    Promise的工作原理
    JS原生的Ajax
    MySQL数据库的基本操作
    & 异步使用场景
  • 原文地址:https://www.cnblogs.com/len3d/p/3079312.html
Copyright © 2020-2023  润新知