{"id":722,"date":"2013-08-14T16:12:00","date_gmt":"2013-08-14T23:12:00","guid":{"rendered":"http:\/\/10kdev.ivystreetinc.com\/?p=722"},"modified":"2013-08-26T14:31:38","modified_gmt":"2013-08-26T21:31:38","slug":"oh-those-interesting-developers","status":"publish","type":"post","link":"http:\/\/10kdev.net\/?p=722","title":{"rendered":"Oh Those Interesting Developers"},"content":{"rendered":"

Good Artists Copy, Great Artists Steal. \u00a0-Pablo Picasso<\/strong><\/em><\/p><\/blockquote>\n

I’m a developer and I can say, first hand, the most difficult thing for a developer to learn is to be open minded and questioning. \u00a0I know, a lot of companies are always looking for developers who will “push the envelope” or “think outside the box” but the reality is there are very few people who do that. \u00a0 Just because you implemented Node.js at your company doesn’t mean you thought outside the box — you didn’t write Node, after all, just got an existing solution to apply to the situation. \u00a0That would be more like “shopping” for the right tool. \u00a0Nothing wrong with that. \u00a0The other creativity can come from the pasting together of such components. \u00a0I think a lot of management misses this idea, but that’s another discussion.<\/p>\n

But seriously, the closed mindedness and need for ego in a lot of developers can be offputting.<\/p>\n

Case in point. \u00a0I worked a gig that had two teams. \u00a0One team was highlighted as a “star team” (so they thought) and the other had a ton of workhorses. \u00a0All the high profile stuff went to the star team and the ditch digging went to the workhorses. \u00a0 \u00a0They had a shared tech meeting, and always the star team got to do presentations, they literally would not let the workhorses do any presentations especially if they had crafted a pattern or solution for the whole codebase. \u00a0 For instance I watched as one straightforward JMX data migration solution was created, then completed ignored and reinvented again by the star team (and worse). \u00a0Over and over this would happen. \u00a0Many of the developers on that team were college interns and would stick hard dates into classes, write up uneeded interfaces (to enums, for instance) — name it, anything short of a go-to. \u00a0 You’d find overengineered solutions and technology for tech’s sake costing hundreds of hours of refactoring. \u00a0Just nasty. \u00a0Worse, would be the “our code” accusations. \u00a0The star team felt they “owned” all their code even thought the base was shared by at least 40 people. \u00a0Seriously? \u00a0Man, none of us own paid for code we were paid to do it for the company. \u00a0They would get nasty if a bug was found or a change would have to get put in. \u00a0The workhorse team got way more done, lower key, less bugs but the egos of the star team got in their way to improve.<\/p>\n

Some time later I went to another team to start up a new application base. \u00a0A month later one of the big “stars” came onto our team, and a few of us were cringing. A lot of the work was in javascript. \u00a0We all knew the scalable and testability problems of javascript and were addressing them, but this person decdided to drop in antiquated libraries and methods *just to get tasks checked off agile boards* and look good. \u00a0I remember at lunch, I was explaining to some junior developers my view of how a rest web app could be looked at as a 2-MVC paradigm and this person refuted me outright saying “javascript isn’t java, so there are no patterns that are similar.” \u00a0I laughed and asked: “Javascript doesn’t follow any software patterns at ALL?” \u00a0And the developer said “no.” \u00a0Star developer, mind you. \u00a0We found this person using collaboration as a crutch for a while and then began to wonder what went on with that star team up there. \u00a0Later, after presenting a wiki piece as their own<\/em> of a Maven build cycle that me and a colleague wrote most of for this developer, they left.<\/p>\n

For anyone to deny that there are personalities involved with software development, or deny that they might like to work with one person more than another, would be foolish. \u00a0I worked on a project where people got hired who hated the very technology they were interviewed for and tried to change it right away . . I mean, WTF. \u00a0But this is reality. \u00a0Paired-programming: you’ll see people gravitate towards preferred pairs. \u00a0I’ve seen it where a person would be paired and never show up working at home. \u00a0I’ve seen mandatory pair rotations end up in someone’s termination based on a personal viewpoint of that person (it was sad to watch, a junior developer got ratted by a skilled person who “didn’t feel it was their job to teach.” \u00a0Dear God.)<\/p>\n

The bottom line here though is, are developers really that sentient and aware of all this? \u00a0I say no, that the gammit of personalities and approaches are in the millions. \u00a0First, so many developers have such great big egos they literally shut their eyes to other points of view. \u00a0This is just a human condition though. \u00a0It’s probably why in People vs. Process, that process wins. \u00a0Most developers do not have any scientific methodology training –i.e. even the understanding of null hypothesis — to be more useful at doing TDD, for instance. \u00a0 Maybe it doesn’t matter though, maybe cranking out 1000 lines an hour is good enough after all, code is not a social artifact its just . . .code.<\/p>\n

Admittedly I’ve been to some of these extremes as well, but have always been mindful. \u00a0Because, after 6 months you won’t remember what it was you were working on so at that time you ARE crafting this solution, do a great job so it doesn’t have to be done again — but that’s the art of it, isn’t it?<\/p>\n","protected":false},"excerpt":{"rendered":"

Good Artists Copy, Great Artists Steal. \u00a0-Pablo Picasso I’m a developer and I can say, first hand, the most difficult thing for a developer to learn is to be open minded and questioning. \u00a0I know, a lot of companies are always looking for developers who will “push the envelope” or “think outside the box” but […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[17],"tags":[],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/722"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=722"}],"version-history":[{"count":9,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/722\/revisions"}],"predecessor-version":[{"id":749,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/722\/revisions\/749"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=722"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}