In The Shadow Of The Ninja

3,085 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,085
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • A code ninja, to me, is someone who lives, breathes, eats and drinks code. They dream in code. They think about code in the shower. They make their living writing code, but it’s more than just a paycheck for them; it’s a way of life. \n
  • A code ninja, to me, is someone who lives, breathes, eats and drinks code. They dream in code. They think about code in the shower. They make their living writing code, but it’s more than just a paycheck for them; it’s a way of life. \n
  • A code ninja, to me, is someone who lives, breathes, eats and drinks code. They dream in code. They think about code in the shower. They make their living writing code, but it’s more than just a paycheck for them; it’s a way of life. \n
  • A code ninja, to me, is someone who lives, breathes, eats and drinks code. They dream in code. They think about code in the shower. They make their living writing code, but it’s more than just a paycheck for them; it’s a way of life. \n
  • A code ninja, to me, is someone who lives, breathes, eats and drinks code. They dream in code. They think about code in the shower. They make their living writing code, but it’s more than just a paycheck for them; it’s a way of life. \n
  • I am not a code ninja. \n
  • I frequently describe my coding style as “a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.”\n\nI could be charitably described as a “mid-level” programmer. I make my living as a php developer for a non-profit company that sells and promotes the use of energy conservation products. Our main line of business is not writing code, it’s selling stuff. As a result, my coding opportunities at my day job are somewhat limited to what will make the company money directly.\n
  • I frequently describe my coding style as “a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.”\n\nI could be charitably described as a “mid-level” programmer. I make my living as a php developer for a non-profit company that sells and promotes the use of energy conservation products. Our main line of business is not writing code, it’s selling stuff. As a result, my coding opportunities at my day job are somewhat limited to what will make the company money directly.\n
  • I frequently describe my coding style as “a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.”\n\nI could be charitably described as a “mid-level” programmer. I make my living as a php developer for a non-profit company that sells and promotes the use of energy conservation products. Our main line of business is not writing code, it’s selling stuff. As a result, my coding opportunities at my day job are somewhat limited to what will make the company money directly.\n
  • I frequently describe my coding style as “a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.”\n\nI could be charitably described as a “mid-level” programmer. I make my living as a php developer for a non-profit company that sells and promotes the use of energy conservation products. Our main line of business is not writing code, it’s selling stuff. As a result, my coding opportunities at my day job are somewhat limited to what will make the company money directly.\n
  • I frequently describe my coding style as “a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.”\n\nI could be charitably described as a “mid-level” programmer. I make my living as a php developer for a non-profit company that sells and promotes the use of energy conservation products. Our main line of business is not writing code, it’s selling stuff. As a result, my coding opportunities at my day job are somewhat limited to what will make the company money directly.\n
  • Magento also scarred me for life.\n\nIt can be a little frustrating, at times, because I feel like I could be doing more, but between my day job and my young family, there’s not a lot of time left to work on other projects. So, I thought to myself, how can I bust out of this mold? How can I become one of those mythical “senior developers” that all the kids are talking about?\n\nThis is what I set to find out. I decided to interview several senior coders in the php and nearby communities. (I define ‘nearby communities’ as communities with members that overlap into the php community; In other words, some people would not define themselves primarily as ‘php programmers’ but still are part of the larger community.) I tried to envision some issues that a senior dev might run into with a junior or mid-level tech newly hired onto their team. (Being able to train/lead is a common thread that ran through a few of the interviews. More on that later.) Eager to pick the sizable brains of these senior developers, I came up with the following list of questions:\n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • These questions are not intended to be exhaustive. They were intended as jumping-off points to stimulate a conversation. \n
  • The interviews were conducted over IRC and/or email. (For those familiar with IRC, this took place on the Freenode IRC network, irc.freenode.net. You can usually find me in #phpc on that network. If you’re not familiar with IRC, Wikipedia has a good tutorial at http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial .)\n\nLet’s expand on each question in turn:\n
  • The interviews were conducted over IRC and/or email. (For those familiar with IRC, this took place on the Freenode IRC network, irc.freenode.net. You can usually find me in #phpc on that network. If you’re not familiar with IRC, Wikipedia has a good tutorial at http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial .)\n\nLet’s expand on each question in turn:\n
  • The interviews were conducted over IRC and/or email. (For those familiar with IRC, this took place on the Freenode IRC network, irc.freenode.net. You can usually find me in #phpc on that network. If you’re not familiar with IRC, Wikipedia has a good tutorial at http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial .)\n\nLet’s expand on each question in turn:\n
  • This question was intended to determine if the senior dev had recent experience in ‘handling’ a junior or mid level coder. (No, not handling like that, you wierdos.) The project portion of the question was there in order to gain some context. For example, was this an open-source project? A private project for-hire for another company? The company’s own code?\n\n
  • We’ve all got bad habits. (Yes, even you.) I wanted to find out how bad they considered ‘bad’, and if I could identify any habits of my own that could stand to be improved as a result of their advice. \n
  • This question recognized the fact that in hiring a junior or mid-level developer, one rarely bats 1.000 on finding someone with *every* skill on the description. (And sometimes you even have to work with a recruiter, who is only searching on buzzwords and doesn’t know the difference between Java and Javascript.)\n
  • Here I’m trying to find out what it is that that developer looks for in a non-senior developer. In other words, if I were applying at their company for a mid-level position, what can I expect, and what is expected of me? And would I get the job? (Probably not, there’s not a lot of call for osCommerce victim.. I mean devs these days.)\n
  • I was trying to dig for hard skills and technologies that would aid in my development. I had been looking for things like unit testing, continuous integration, coding style evaluation (as in PHPCodeSniffer), and so forth. Lots of people came back to this question with answers to different questions, as we’ll see.\n
  • A light at the end of the tunnel is always nice. Unless it’s a train approaching.\n
  • Again with my search for solid facts. I guess I was operating under the delusion that there was some secret sauce to ‘becoming senior’ that could cut effort and time out of the equation. Man, for just once, couldn’t there be some simple answers?\n
  • One of the ways I defined ‘code ninja’ is ‘produces prodigious amounts of valuable code’. Therefore productivity is an important aspect to evaluate, and for me to be concerned with.\n
  • This is intended to be an opportunity for the interviewee to include things that may not have come up during the natural course of the conversation, but they would like to include.\n\nQuotes are direct when “quoted”, otherwise are paraphrased using my own howler-monkey inspired internal filter.\n
  • Ben told me he was honored to be interviewed for this talk.\n\nBen said that he had recently been in a position to orient a new developer onto a project that he was involved in. (bio) He described the dev as mid-level. As per the usual situation, there was very little time to get someone up and running. In this case, the developer was being placed on “more of a legacy project”, with a large codebase and a fair degree of complexity. He (the developer) had expressed frustration that he had been there for a week and hadn’t been able to commit any code as of yet. Personally, I think a couple of weeks is a fair amount of time to expect that on a project of this level of complexity, but in a start-up situation like what Ben is involved in, things have to happen very quickly and there isn’t a lot of time available for mentoring and helping more junior developers to grow. He mentioned that at a previous position he had much more time for mentoring, and appreciated that fact; however, that was an agency of 350 people, so there were more resources available. We decided to focus on this past situation.\n
  • Ben went on to say that the code reviews in particular (this would be a good time to start taking notes if you’re so inclined) were extremely helpful (in fact, the word he used was “critical”) to the agency’s success and the growth of the more junior developers. \n\nHe described a situation where the team would all gather in a room for an hour a week and review each other’s code. (I should mention here that that’s one of my definitions of Hell. Getting over my fear of code reviews is a step that I need to take, and I daresay there are others in this room that need to do the same thing.) “Check your ego at the door” was the order of the day in these reviews. Ben thanked Brian DeShong for his assistance in general and in particular during code reviews. (We’ll meet Brian later.) \n
  • Ben related a situation in which one developer in particular was having trouble following coding standards, and through code review (Ben used the word ‘nitpicky’) was able to clean it up.  That’s a concrete example of someplace where a dev can improve.  It turns out to be a tradeoff; if you can stand people looking at your code, you will become a better coder in spite of yourself.\n\nAs far as what core technologies the new hire was expected to be familiar with, Ben said that new hires at his agency were really only expected to know PHP and Zend Framework as far as programming was concerned (yes, I know Zend Framework is ‘just a framework’.)  However, other technologies they were expected to be able to understand and use were Subversion and PHPUnit, as well as a working knowledge of webapp security.  Developers there were encouraged to use any hardware or software tools (OS, IDE, so forth) that they were comfortable with.  \n\nWhen a gap in knowledge was identified, a junior dev would be paired with the best senior dev for the job.  They’d be assigned a task and would work together on it.  It wasn’t formal “pair programming”, but the two developers would be working on the same pieces of the project.  Through this, the job would get done, the junior dev would grow as a programmer, and knowledge would be shared.\n\nBen also had had the opportunity to interview new candidates at his previous position.  He did not use a script, in order to get a better feel for the person’s personality.  One question he would ask would be for the candidate to describe, in their own words, what they were doing at their current position.  Then he would ask some general questions about webapp security, to see if they were current on their knowledge of SQL injection, XSS attacks, and CSRF attacks.  (Good things to bone up on if you’re not familiar, or don’t know them by those names.)  He’d then do the same with design patterns; again, if they had implemented the pattern but didn’t know it by its formal name, he would lead them a bit.\n\nWhen I asked what technologies that a coder should familiarize themselves with in order to progress, Ben related the following:\n
  • \n
  • Oh noes, the dreaded ‘soft skills!’  Others echoed this sentiment.  Hmm, maybe there’s something to it...  Ben told me a senior dev needs to be able to lead a team, directing work by “picking the right people to do certain pieces of the project.”.    Not the dreaded “manager” word, but managing the technical issues is important.  \n\nAs far as particular technologies are concerned, Ben also cautioned about over-specialization, where you focus on one area to the exclusion of others.  “You can specialize yourself out of a job.”  That being said, he indicated that skills involving scaling are definite pluses to your growth as a developer.  Optimizing your PHP, your database queries, and using APC effectively were some particular points he touched on.  Then the “cloud” was mentioned. (DRINK!)  \n
  • Having some sysadmin experience is also important, according to Ben.  Being able to work in a *NIX terminal, and having some familiarity with Amazon’s EC2 were two things he mentioned in particular.  \n\nWhen asked about a reasonable time-frame for ‘becoming senior’, Ben described situations in which someone had been promoted to a “Senior” title soley due to their time on the job.  People felt entitled to be called “senior” because, for example, they had been working on a project for eight years.  You might have the title, but unless you take the initiative to further yourself, you’ll only be senior in title.  It also makes changing jobs difficult, since in your current position you will have worked yourself into a nice little coding rut.  He did mention that this doesn’t happen much in start-ups.  (elaborate here)\n\nWhen we talked about what resources one should use to develop, most of my interview subjects mentioned IRC.  (I’ll put the information back up at the end of the slides if you missed it or were getting coffee or were waking up or something.)  Ben also mentioned going to conferences (yay!) and George Schlossnagle’s Advanced PHP Programming.  (insert picture of cover if available.)  \n\nWhen asked about measuring productivity, Ben couldn’t say he had good metrics for that, such as bugs fixed or keystrokes per day.  (Who does that, honestly? Not anyone I want to work for, that’s for sure.)  Ultimately, it comes down to a subjective judgment: “Are they getting the job done?”  or “Are they slowing down the team?”  If not/so (that’s awkward), then it’s the job of the more senior developers to identify the places where the more junior dev is stumbling, and the job of the more junior devs to ask for help.\n
  • If you find yourself in a position where you’re not growing, or you don’t like it, then it’s on you to either find a job that allows you to grow, or find a project you can work on to stretch your boundaries.  It’s your responsibility to grow, not your employer’s.  \n
  • \n
  • Brian and I spent a lot of time talking about the hiring process and working environment of a company he worked for for nearly five years.  I’m including a lot of detail here because some of you may be pondering the move to a bigger company (or just a different company) and would like to know what to expect.\n\nBrian related a story about orienting a new hire onto the project he was working on in late 2008 to mid 2009, which involved re-architecting an 8+ year old B2B application for a major cable television network.  This application would allow affiliates to get promotional materials, schedules, various legal agreements, and so forth, and provide information back to the network’s home office.  Brian was the lead on the project.  \n\nBrian described one junior developer that had been assigned to the project. He indicated that one disadvantage that the new hire had was that, while that person had years of PHP and OSS experience, their coding style was not in line with the company’s standards.  Things like spacing, class, method, and variable naming standards, so forth.  The coding style in question was described as ‘ZF standards plus our custom, company-specific additions’.  They had tried to implement PHPCodeSniffer, but in the end were not able to, “but not for lack of trying”.\n\nTheme alert: The tool Brian described as most useful was the code review.  (Groan.)  Code reviews were conducted once or twice a week at the most, with fewer unfortunately happening in the final months of the project.  Volume of code generated would sometimes dictate when a review happened, limited to two hours max.  \n\nWork was conducted in two week sprints, with the goal being a feature completed in each sprint.  Some larger features took up two to three sprints.\n
  • Brian was not only the leader on this project, but wrote “a LOT” of code in the final months, while also coordinating with the client on web service APIs and advising them on hardware, hosting setup, and other practical concerns.  \n\nA new hire to this project was expected to be experienced with PHP, MySQL, Linux, Memcached, and Zend Framework, which unfortunately was completely new to the new hire.  We then commiserated for a few minutes on how big a PITA Zend_Form can be to work with.  (No offense, MWOP.)  \n\nThe new hire was not expected to be especially familiar with code reviews and/or unit testing.  Some unit testing was used on the project; they approached 70% code coverage after all was said and done. \n\n
  • Sadly, unit testing is one of the first things to go when the excrement hits the air circulation device.  (Howler monkey joke here?  Slide with the same picture?)  \n\nDuring Brian’s time at this company, he had the opportunity to interview many mid-level coders.  I asked him what was the one thing that he saw as missing from the toolkits of those he interviewed.  “Definitely the experience with unit testing.”  He also mentioned that most mid-level coders have touched databases but not in a very advanced way.\n
  • As far as interview questions in particular went, Brian’s style was to first ask them what they were most proud of in their career; the application they had the most pride in, and then describe what their biggest challenge/failure has been.  They would then get some take-home work if they seemed like a good fit after a phone screen.  \n\nWe then talked about toolsets to enable progression to a senior level.  Brian identified caching technologies as being significant, as being able to design high performance, scalable applications is a skill essential to being a senior developer.  In addition, having a good sense of database design, considering normalization of data and design and implementation of a data model, and efficient indexing strategies were all important.  \n\nGood software design came up as well.  \n
  • (Hey, I’m not Terry Chay, I can’t get away with naughty words.)  \n\nDuring the course of my interviews, a common thread was that the difference between a mid-level coder and a ‘senior’ coder was that a mid-level coder can code, while a senior developer can lead.  Asked about this:\n
  • Asked about a time-frame for developing into a senior coder, Brian gave a no-less-than 2 year journey from mid-level to senior, with 2 to 4 being more common.\n
  • For the managers in the audience:  NOBODY can go from mid-level to senior in a year.  It just doesn’t happen:\n
  • Brian had a number of resources to draw on, having once worked for a company that had a required reading list:\n
  • \n\n\n
  • He also identified phpdeveloper.org and planet-php.net as a good way to keep your finger on the pulse of the community.  Also, Etsy’s “Code as Craft” blog.  And shocker, he also mentioned #phpc on IRC.  (Yes, I’ll put that back up at the end of the talk.)\n\nSomething else he recommended was learning a new programming language.  He described it as useful for seeing development from other perspectives.  “Always be learning something new.”\n\nWe then talked about how to measure coders’ productivity.  Brian kept an eye on Subversion commit logs as a good indicator of what someone is generating in a given time period.  He also would check in daily with his developers in a stand-up meeting asking three questions:\n
  • He said that helps to keep everyone accountable.  Code reviews were also used in productivity measurement.\n\nFinally, some general advice:\n
  • \n
  • Matt had an opportunity to orient a new juniorish developer who was replacing him at his place of employment.  The project was a LAMP application used by vascular surgeons for data management, accreditation and quality assurance purposes.  The replacement had had little experience with frameworks, and Matt had started writing a new version of the application using jQuery and Zend Framework.  The new developer had had some unfortunate experience in seeing code that was poorly designed and came from “environments where people were very resistant to change.”  \n\nMatt told me that his replacement needed to be brought up to speed on the finer points of PHP object oriented programming, as well as more expertise in documentation and testing.  Client-side code was also an issue.  We talked a little bit about the current state of affairs in Javascript programming, and talked a little bit about some Javascript frameworks that we’d both used (mostly jQuery).  One strength that this new developer had was consistency in his coding style and practice; previous poor experience had taught him the value of things like code reuse. \n
  • (Unfortunately the state of the code was such that the older code did not have a consistent coding style or standard that could be used with automated tools, while at the time Zend Framework was new enough to where there weren’t really good rulesets for things like CodeSniffer yet.)\n\nMatt had expected familiarity with PHP and MySQL from this developer coming through the door, but found that he did not have the degree of familiarity that he had quite been looking for, especially when faced with the task of building a development environment with them.  His experience had been largely on the desktop.  \n
  • We talked for a time about the difficulties of being a one-man show as opposed to working within a team of developers, and how the community, great as it is, is no substitute for working with someone on the same project in a professional setting.  Matt agreed with me that it’s easier to progress past a ‘mid-level’ point of stagnation if you’re working as part of a team, because you always have someone to learn from, even if they’re not necessarily ‘senior’ to you.  \n\nWe turned then to the topic of technical interviews, and Matt expressed some dismay at the fact that he’d never been included in an interview himself.  He expressed a belief that having your dev team in on an interview in some form is a good practice:\n
  • Asked about technologies that someone should become proficient with in order to progress to a more senior level, Matt again turned the tables on me, expressing the opinion that it wasn’t experience with technologies that makes a senior-level developer, and what does is “being able to adapt oneself to technologies outside of one’s comfort zone, which comes from the breadth of one’s experiences.  To that end, experience with a variety of languages and paradigms is essential.”\n\nMatt then listed understanding the difference between strong and weakly typed languages (for example, Java or C# versus PHP, Perl, Python or Ruby), having knowledge of and experience in procedural, functional, and object-oriented paradigms, and knowledge of at least one relational and at least one non-relational database as vital skills needed for one to progress.  \n\nAs far as a developmental timeline was concerned, Matt said that he’d seen that most senior developers had had 7 to 10 years of experience in their field, but that it really depended on the person and how they approach their career:\n
  • I then asked if one could expand beyond ‘day coder’ status, in his opinion, if one were to do side work on either an open source project or a for-pay coding gig, that that would bust one out of the ‘9-5’ mode.  Since there was the potential for a variety of experience being gained, then one would stand a better chance of not becoming a “day coder”, or busting out of the role if one had fallen into the trap already.  \n\nI asked about resources to recommend, and Matt indicated that he’d personally stopped reading RSS feeds and the like and generally got his news through Twitter or Facebook, from coworkers, or from books.  He recommended books from O’Reilly, Wrox, and Apress.  (As well as his own book, php|architect’s Guide to Web Scraping with PHP. Ding.)\n\nAs far as measuring productivity went:\n
  • A final quote:  “We’re all teachers and we’re all students.”\n
  • Eli and I spent a few minutes complaining at each other about Facebook crashing Firefox, and then we got down to business.\n\nAt each of Eli’s recent positions, he was involved in hiring, orienting, and managing junior to mid-level developers.  Each of those projects involved large internal web applications, with as few as three and as many as 50 developers on a team, with 12 being typical.  All were focused on one project.  He remarked about how many PHP developers work in the contracting world, where everyone is kind of working on their own individual part of the project.  \n\nEli mentioned ‘overengineering’ as being on his list of regrettable habits he saw from the developers he oriented and managed.  For example: “Relying on ‘tricks’ in the code, one line that does a ton of work but is mindboggling versus understandable code.”  He also mentioned a lack of commenting as being a pet peeve.  He described what he called the ‘ooh shiny’ syndrome, where the new hotness gets all sorts of attention and is then gone the next year.\n
  • Juniors tend to have a strong push towards ‘stock solutions’ rather than building something yourself, he said.  The importance of stock solutions should not be under-emphasized, they are useful when available and appropriate, but it should be known when to write something yourself.\n
  • As far as the skills Eli expected new hires/midlevel developers to come through the door with, he mentioned a working knowledge of Javascript as being essential.  He pointed out how lots of new web applications are heavy on the AJAX/JavaScript, and it’s “awkward to have someone on the team who can’t do it at all.”  He pointed out that ‘fix this’ tasks frequently involved both PHP and JavaScript.  I asked if jQuery knowledge would satisfy that kind of requirement, and he agreed that it would.\n
  • In terms of what other technologies would be important, I asked about things like SVN, unit testing, CodeSniffer, and so forth, and he admitted the following:\n
  • Eli had mentioned earlier that he’d been involved in hiring new developers.  He expressed some dismay at the quality of candidates that had come from either Monster.com or outside recruiters.  He had found better luck with candidates that ‘knew someone who knew someone’, or had reached out to a company and said “I want to work for you.”  He also expressed some frustration at developers that didn’t seem to be PHP developers so much as developers that only worked with certain frameworks.  \n\nEli had given developers take-home coding tests, simple things like an application to add and edit user accounts with things like name, address, phone, likes and dislikes, and so forth.  He’d give these tasks and then when he got the results, one of the things he asked about was how long it had taken the candidate to write it.  This seemed to avoid what he called ‘test panic’ on the part of the candidate; some people who are awesome coders would not make it past that kind of interview.  He’d have rather discussed the resulting code in terms of ‘Why did you do X’ or ‘What about Y?’ or ‘Look, you have a security hole here, can you explain it?’  Also evaluating how complex the application is to perform what is essentially a simple task was a tool he employed.  \n\nAsked about what technologies the mid-level developer should become familiar with, he (like others) turned the tables on me and asserted that it wasn’t a technologies thing, it was an experience thing.  In a mid-to-senior transition, he expected to see people getting involved outside of work.  For example, attending conferences (and maybe trying to speak at one), getting involved in user groups, blogging, so forth.  He said he expected the senior developer to be looking at and understanding the bigger picture, and a breadth of experience is required in order to be able to do that.  \n\nEli gave a big “it depends” answer when asked about a time frame to transition from mid-level to senior.  \n
  • Community was the biggest thing he mentioned when asked about resources to tap into.  He suggested local user groups, conferences, and IRC as being good examples of how to get involved in the community.  As far as sites went, he described phpdeveloper.org as being a good place to share “the 'cool' around the web of PHP.”  \n
  • \n
  • Task completion was the most important thing Eli described when asked about how to measure a coder’s productivity.  \n
  • As far as general advice to give to a mid-level coder, Eli again emphasized community:\n
  • \n
  • Cal and I talked about a hypothetical mid-range developer, as he hadn’t recently had occasion to orient one.  \n
  • Cal expects his mid-level coders to be masters at the language in question.  \n
  • Cal is also of the opinion that it’s not use of particular technologies that will enable you to make the transition from mid-level to senior.  Pressed on this point, when asked if there was something to use to become a better coder, Cal turned the question on its ear and said the following:\n
  • So again, it appears that making the transition from mid-level to senior appears to be a collection of ‘soft skills’.  In other words, if you don’t have your coding skills honed to a fine edge, then the transition from mid-level to senior is going to remain out of your grasp.  Asked about a time-frame, Cal answered thusly:\n
  • Food for thought, maybe?  It seems like at the point at which you call yourself ‘mid-level’, you have a few paths open to you.  If you don’t see yourself coding forever, and you’d like to work with people more, then management is an option.  Personally, I’d much rather have a manager that can code than some MBA who needs help to tie his code shoes...\n\nAs far as resources for furthering one’s progress, Cal recommended reading everything you can find about mentoring. However, actions speak louder than words:\n
  • We then moved on to discussing measuring coder’s performance and productivity.  Cal expressed a belief that nobody should manage software developers that hasn’t been a developer themselves.  \n
  • When asked for some general advice for a mid-level coder as they ponder a transition:\n
  • \n
  • So what have we learned?\n\nMake sure you know where you want to go\n    Managing?\n    Coding?\n    Other paths?\n\nMentoring GOOD\n\nBad habits to break:\n    Inconsistent code style\n    Poor documentation\n    Overengineering\n    Reliance on a particular framework as opposed to “raw coding”\n    “Hackish” approaches to problem solving without a deeper understanding of what’s really         going on in the code\n\nCode reviews are a useful tool to improve your code (style and content) and coding habits\n    PHPCodeSniffer\n\nStuff to come in the door with:\nSubversion, PHPUnit(frequently missing)\nWebapp security (know what SQL injection, XSS and CSRF attacks are)\nLinux, Memcached, ZF (if it’s a ZF shop)\nKnowledge of one JavaScript library (jQuery, prototype, so forth)\nAJAX\nMySQL (or some other relational DB system)\nOne non-relational database\n\nQuick explanation of SQL injection, XSS attacks, CSRF attacks?\n\nSoft skills separate mid-level devs from senior devs - mid-level coders should be able to code like seniors, with the difference being:\nMentoring\nLeading\nDirecting\nHelping other developers past difficulties\nMoving outside your “comfort zone”\nGetting involved outside of work\n\nScaling skills important\n    Memcached\n    *nix terminal\n    DB caching\n\nWorking as part of a team makes things a little easier\n    \n\nTime frame\n    “Soft” time frame\n    Anywhere from 2 to 6 years\n    Never get there if you only code ‘9 to 5’\n
  • \n
  • \n
  • In The Shadow Of The Ninja

    1. 1. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    2. 2. In The Shadow Of The Ninja Biding Your Time While Plotting Your Coup Zachary Burnham Energy Federation Incorporated May 27, 2011
    3. 3. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    4. 4. So who is this guy, anyway?Zend Certified Engineer (5.3)Zend Framework contributorphp|architect Technical EditorFull time php developer at Energy Federation Incorporated (http://www.energyfederation.org, http://www.efi.org)I’m just this guy, you know?zburnham@gmail.com, @zburnham, http://www.zacharyburnham.com Zachary Burnham Energy Federation Incorporated May 27, 2011
    5. 5. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    6. 6. .ninja { color: black; visibility: hidden;} What is a “Code Ninja”? Zachary Burnham Energy Federation Incorporated May 27, 2011
    7. 7. class Zach extends Huge_Nerd{ ... protected $isNinja = false; ...} Zachary Burnham Energy Federation Incorporated May 27, 2011
    8. 8. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    9. 9. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    10. 10. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    11. 11. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    12. 12. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    13. 13. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    14. 14. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    15. 15. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    16. 16. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project? Zachary Burnham Energy Federation Incorporated May 27, 2011
    17. 17. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies? Zachary Burnham Energy Federation Incorporated May 27, 2011
    18. 18. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies?3. What core technologies did you expect them to be familiar with, other than theprogramming language in question? What was the reality? Zachary Burnham Energy Federation Incorporated May 27, 2011
    19. 19. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies?3. What core technologies did you expect them to be familiar with, other than theprogramming language in question? What was the reality?4. Have you ever been in a position to interview someone for a junior or mid-levelposition? Recently?4a. What questions did you ask in that interview? Zachary Burnham Energy Federation Incorporated May 27, 2011
    20. 20. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies?3. What core technologies did you expect them to be familiar with, other than theprogramming language in question? What was the reality?4. Have you ever been in a position to interview someone for a junior or mid-levelposition? Recently?4a. What questions did you ask in that interview?5. If a mid-level coder came to you and asked what technologies they shouldfamiliarize themselves with in order to progress to a senior level, what would you tellthem? And, why those particular technologies? Zachary Burnham Energy Federation Incorporated May 27, 2011
    21. 21. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies?3. What core technologies did you expect them to be familiar with, other than theprogramming language in question? What was the reality?4. Have you ever been in a position to interview someone for a junior or mid-levelposition? Recently?4a. What questions did you ask in that interview?5. If a mid-level coder came to you and asked what technologies they shouldfamiliarize themselves with in order to progress to a senior level, what would you tellthem? And, why those particular technologies?6. How long is a reasonable time-frame for a mid-level coder to becomesenior, if they follow your advice? Zachary Burnham Energy Federation Incorporated May 27, 2011
    22. 22. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies?3. What core technologies did you expect them to be familiar with, other than theprogramming language in question? What was the reality?4. Have you ever been in a position to interview someone for a junior or mid-levelposition? Recently?4a. What questions did you ask in that interview?5. If a mid-level coder came to you and asked what technologies they shouldfamiliarize themselves with in order to progress to a senior level, what would you tellthem? And, why those particular technologies?6. How long is a reasonable time-frame for a mid-level coder to becomesenior, if they follow your advice?7. What resources would you recommend? (ie community, sites,books, etc) Zachary Burnham Energy Federation Incorporated May 27, 2011
    23. 23. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies?3. What core technologies did you expect them to be familiar with, other than theprogramming language in question? What was the reality?4. Have you ever been in a position to interview someone for a junior or mid-levelposition? Recently?4a. What questions did you ask in that interview?5. If a mid-level coder came to you and asked what technologies they shouldfamiliarize themselves with in order to progress to a senior level, what would you tellthem? And, why those particular technologies?6. How long is a reasonable time-frame for a mid-level coder to becomesenior, if they follow your advice?7. What resources would you recommend? (ie community, sites,books, etc)8. How do you measure junior coders productivity, if youre in aposition to do so? Zachary Burnham Energy Federation Incorporated May 27, 2011
    24. 24. 1. Have you been in a position recently to have to orient a junior- to mid-leveldeveloper? What was the nature of the project?2. Did they come in with less than optimal coding habits/styles/philosophies?3. What core technologies did you expect them to be familiar with, other than theprogramming language in question? What was the reality?4. Have you ever been in a position to interview someone for a junior or mid-levelposition? Recently?4a. What questions did you ask in that interview?5. If a mid-level coder came to you and asked what technologies they shouldfamiliarize themselves with in order to progress to a senior level, what would you tellthem? And, why those particular technologies?6. How long is a reasonable time-frame for a mid-level coder to becomesenior, if they follow your advice?7. What resources would you recommend? (ie community, sites,books, etc)8. How do you measure junior coders productivity, if youre in aposition to do so?9. Any general advice that youd give a mid-level coder? Zachary Burnham Energy Federation Incorporated May 27, 2011
    25. 25. IRC Zachary Burnham Energy Federation Incorporated May 27, 2011
    26. 26. IRC Freenode IRC net work, irc.freenode.net #phpchttp://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial Zachary Burnham Energy Federation Incorporated May 27, 2011
    27. 27. 1. Have you been in aposition recently to have toorient a junior- to mid-level developer? What was the nature of the project? Zachary Burnham Energy Federation Incorporated May 27, 2011
    28. 28. 1. Have you been in aposition recently to have toorient a junior- to mid-level developer? What was the nature of the project? Zachary Burnham Energy Federation Incorporated May 27, 2011
    29. 29. function destruct($object){ if (is_array($object)) { foreach ($object as $obj) { destruct($obj); 2. Did they come in with } } elseif (is_object($object)) { less than optimal coding if (in_array(‘__destruct’, get_class_methods($object ))) { habits/styles/ $object->__destruct(); } } philosophies? unset($object);} (yes, that’s Magento code) Zachary Burnham Energy Federation Incorporated May 27, 2011
    30. 30. 3. What core technologies didyou expect them to be familiar with, other than the programming language in question? What was the reality? Zachary Burnham Energy Federation Incorporated May 27, 2011
    31. 31. 4. Have you ever been in a position to interview someone for a junior or mid-level position? Recently? 4a. What questions didyou ask in that interview? Zachary Burnham Energy Federation Incorporated May 27, 2011
    32. 32. 5. If a mid-level coder came to you and asked what technologies they should familiarizethemselves with in order to progress to a senior level,what would you tell them? And, why those particular technologies? Zachary Burnham Energy Federation Incorporated May 27, 2011
    33. 33. 6. How long is a reasonable time-frame for a mid-levelcoder to become senior, if they follow your advice? Zachary Burnham Energy Federation Incorporated May 27, 2011
    34. 34. 7. What resources would you recommend? (iecommunity, sites, books, etc) Zachary Burnham Energy Federation Incorporated May 27, 2011
    35. 35. 8. How do you measure junior codersproductivity, if youre in a position to do so? Zachary Burnham Energy Federation Incorporated May 27, 2011
    36. 36. 9. Any general advice thatyoud give a mid-level coder? Zachary Burnham Energy Federation Incorporated May 27, 2011
    37. 37. Ben Ramsey is the Vice President of Engineering at Moontoast, the SocialCommerce Network. He is also a leader in the PHP community—the founder ofthe Atlanta PHP user group, the organizer of the Nashville PHP user group, thefounder of the PHP Groups user group network, a founding member ofPHPCommunity.org, and a speaker at industry conferences worldwide.Ben has written for php|architect, International PHP Magazine, and ZendDeveloper Zone and has contributed to several books, including php|architect’sZend PHP 5 Certification Study Guide (Marco Tabini & Associates) and PHP 5Unleashed (Sams). Zachary Burnham Energy Federation Incorporated May 27, 2011
    38. 38. Ben RamseyBen Ramsey is the Vice President of Engineering at Moontoast, the SocialCommerce Network. He is also a leader in the PHP community—the founder ofthe Atlanta PHP user group, the organizer of the Nashville PHP user group, thefounder of the PHP Groups user group network, a founding member ofPHPCommunity.org, and a speaker at industry conferences worldwide.Ben has written for php|architect, International PHP Magazine, and ZendDeveloper Zone and has contributed to several books, including php|architect’sZend PHP 5 Certification Study Guide (Marco Tabini & Associates) and PHP 5Unleashed (Sams). Zachary Burnham Energy Federation Incorporated May 27, 2011
    39. 39. “Ive never worked for an agency where we had a formal mentoring program, but yes, when I started there, the team I worked on had junior- and mid-level developers.Brian DeShong was instrumental in establishing our coding standards and code review practices.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    40. 40. “I think for the senior devs to point out their own weaknesses in the code,it was good for the junior devs to learn from that and to understand that we were are trying as a team to build the best possible software, and with thatin mind, it wasnt a destructive review, but rather, constructive.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    41. 41. “I think that being "senior" encompasses more than just knowing more technologies. In fact,while I think a senior developer does need to have a handle on a lot of different technologies, theywill somewhat forego their "jack-of-all-trades" thatseems to come with being more of a mid-level dev.… I think "soft skills" and leadership abilities startbecoming more important, and ... narrowing focus into specialties is part of it. … I do feel that being "senior" is more of a mindset and it comes with time and experience. Theres a certain confidence that comes with doing things over a long period of time. You can use that confidence to start leading others.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    42. 42. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    43. 43. OH NOES! Zachary Burnham Energy Federation Incorporated May 27, 2011
    44. 44. “Everyones talking about the "Cloud" these days, and what that really means [to me] is that service-oriented architectures are becoming more and more important, so knowing how to connect to and integrate with web services is key.”(“Cloud”, get it?) Zachary Burnham Energy Federation Incorporated May 27, 2011
    45. 45. “The best senior-level developers are the ones who strive to be the best at what theyre doing, so theadvice I would give anyone is to be your best. Thats really cheesy-sounding, but I honestly believe it. Strive to be your best, and it willshow. If you just sit around all day, just getting by and never going above and beyond, then thatll show, too.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    46. 46. “I never really thought of myself as working towards being a "senior" developer. Ive alwaysjust wanted to learn and be the best I could be atwhat Im doing. In my experience, thats really the mindset it takes. Its a journey, and Im by no means at the end of it. I dont think you shouldwait to be the "senior" anything. Just always strive to be better at what you do, and youll find yourself there. …  I feel like a damned motivational speaker now.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    47. 47. Brian DeShong is an Atlanta-based seniorsoftware engineer for Yahoo!. Brian has 12years of experience in software development,architecture, systems administration, andtechnical leadership. He specializes in PHPand open source technologies. Zachary Burnham Energy Federation Incorporated May 27, 2011
    48. 48. Brian DeShongBrian DeShong is an Atlanta-based seniorsoftware engineer for Yahoo!. Brian has 12years of experience in software development,architecture, systems administration, andtechnical leadership. He specializes in PHPand open source technologies. Zachary Burnham Energy Federation Incorporated May 27, 2011
    49. 49. “The idea was to have user experienceand design done and signed off on before we started building a feature.  It didnt always work out perfectly, but if UX/ design was behind, wed at least startback end code and foundational stuff forthe component at the start of the sprint.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    50. 50. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    51. 51. “The types of projects Ive worked on and led over the years are the kind that involve a lot of clever use of databases and caching.  So, getting them schooled on that kind of stuff is pretty common.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    52. 52. “It sounds cliche, but books like Design Patterns are a great reference.. The Gang of Four (and others) have come up with elegant solutions to very common problems in software development.  So, rather than rollingyour own and thinking youre smarter than the average bear, its better to stand on the shoulders of giants and leverage the thinking thats already been done ...most of the time.  Not always, but most of the time. For example, if you apply, say, classic Active Record, and your site runs like [stuff], then you fail.  So,take advice from so-called "experts" and master architect-types, but use your own common sense and reasoning to determine if a given solution is A) best for you, and B) is going to scale.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    53. 53. “I say thats absolutely true.  Leading a team, or atleast leading an effort on a project, is key to being senior...  Or, at the very least, you need to be EXTREMELY reliable and dependable.  And always deliver high quality work, on time.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    54. 54. “If theyre looking back [at] old code and NOTsaying "what the hell was I thinking?" then that means theyre not learning and growing as a developer.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    55. 55. “Ive seen managers promote people one level up for a year.  Those managers, frankly, are [stuff]y and should be fired. Theyre doing aHUGE disservice to themselves, the developer themselves, and all of their co-workers by promoting people prematurely.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    56. 56. The Pragmatic ProgrammerThe Mythical Man-MonthCode Complete 2The Object-Oriented Thought Process Zachary Burnham Energy Federation Incorporated May 27, 2011
    57. 57. http://www.phpdeveloper.orghttp://planet-php.nethttp://codeascraft.etsy.com/#phpc Zachary Burnham Energy Federation Incorporated May 27, 2011
    58. 58. What did you do yesterday?What are you doing today?Is anything standing in your way? Zachary Burnham Energy Federation Incorporated May 27, 2011
    59. 59. “Always be enhancing your skills andgaining more experience.  Its key to growing your career.   Work with others.  Question everything.  If you dont believe in something, say so.  Dont be a sheep.  Andalways look back at your work with a critical eye.  Refactor.  Improve.  And...be reliable.  Become someone that others can depend on to deliver quality software, on time, and to specification.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    60. 60. Matthew Turland has been working with PHP since2002. He has been both an author and technical editorfor php|architect Magazine, spoken at multipleconferences including ZendCon and php|tek, served asan instructor for php|architect training courses, andcontributed to Zend Framework. He holds the PHP 5and Zend Framework certifications and is the authorof php|architect’s Guide to Web Scraping with PHP.He currently works as a Senior Engineer for Synacor. Zachary Burnham Energy Federation Incorporated May 27, 2011
    61. 61. Matthew TurlandMatthew Turland has been working with PHP since2002. He has been both an author and technical editorfor php|architect Magazine, spoken at multipleconferences including ZendCon and php|tek, served asan instructor for php|architect training courses, andcontributed to Zend Framework. He holds the PHP 5and Zend Framework certifications and is the authorof php|architect’s Guide to Web Scraping with PHP.He currently works as a Senior Engineer for Synacor. Zachary Burnham Energy Federation Incorporated May 27, 2011
    62. 62. “Designing and maintaining code to be flexible that way isnt really somethingthat can be taught or communicated in so many words.  So, I guess thats part of what comes with experience.  School generally hands you requirements that dont change. Contrasts to the real world that way.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    63. 63. “Hes closer to mid-level now, but not quite ready to move far outside his comfort zone. I think to a certain degree that thats something thatseparates a mid- from a senior-level.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    64. 64. “If someone doesnt mix well with your team in an interview, thats a good indicator they might not work well together.  You can teach an unskilleddeveloper skills. Teaching someone whos not used to working with a team orprefers to operate independently to work well with one [is not as easy] in my opinion.  Being able to collaborate andcommunicate are essential.  A lot of times,were not just writing code: were bridgingthe gap between people and technology.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    65. 65. “Your job can’t be a 9-5 if you ever hope to be trulygood at it. Work is a great opportunity to sharpen your skills, but it can’t end there or your progress will be slower by orders of magnitude. The field has to be something you’re passionate about. You have to careabout what you produce and not just because you want to avoid pain or annoyance later on. You must have a genuine want to learn, expand, and grow, and that can never stop. Tech has been a whirlwind of change for the last 40 years and it’s not showing any signs ofstopping. Nor will we be able to. A lot of developers in my area are what I call “day coders”. To them, it *is* a 9-5. And they’ll only get to be so good at it because of that.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    66. 66. “If there was an effective objective means of measuring productivity, it would probably have already had widespread implementation in the industry. Realistically, I think it can be gauged to a certain extent by how many questions they ask, how resourceful they prove to be at learning things on their own, how much time they spend working, how many(Questions. derp.) errors they make, etc.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    67. 67. Eli has worked in/on/around the internet for over 16years, with the last 10 spent exclusively with PHP.  Hehas worked a number of varied jobs in the past,including HiiDef/Goodsie, Zend, TravelPod/TripAdvisor, Digg and for the Hubble Space TelescopeProgram. He is co-author of the book PHP 5 inPractice and has presented at numerous conferences. Zachary Burnham Energy Federation Incorporated May 27, 2011
    68. 68. Eli WhiteEli has worked in/on/around the internet for over 16years, with the last 10 spent exclusively with PHP.  Hehas worked a number of varied jobs in the past,including HiiDef/Goodsie, Zend, TravelPod/TripAdvisor, Digg and for the Hubble Space TelescopeProgram. He is co-author of the book PHP 5 inPractice and has presented at numerous conferences. Zachary Burnham Energy Federation Incorporated May 27, 2011
    69. 69. “Ive noticed that lots of juniors, not having had their soul crushed yet, are excited about every new tech that appears, and immediately will want to use it in production :)” Zachary Burnham Energy Federation Incorporated May 27, 2011
    70. 70. “Now, of course its important to USE stock solutions when they are available and solve a need.  But you also need to know when the situation just calls for doing something yourself.  Ive had people come into a situation, andimmediately start ripping on the existing codebase because its not <insert big name framework> … or because it doesnt use a certain design pattern, orbecause its not using a certain templating engine, etc.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    71. 71. “As long as you understand the basics of being able to write javascript, and as long as you show that you can do basic AJAX- like-stuff with one of the many libraries,then its met. You dont need to understand the deep core event model, or stuff like that.   Heck, Ive forgotten all that myself at the moment, because the libraries exist to shield you from that.  Wipe that part of brain, inject jQuery instead”. Zachary Burnham Energy Federation Incorporated May 27, 2011
    72. 72. “Stuff like Unit Testing, well, dirty little secret, Ive done verylittle of it.  Again its been because of the nature of the projectsI work on...   Early stage rapidly changing rapid development, recode your whole system every 6 months type projects … unit testing, IMO, ends up getting in your way more than it helps you.” … “To me, I find that there is a right time and place for it.  Once you have a stable application, out of beta, and in maintenance mode, is an AWESOME TIME to add it. But when you are in the rip rebuild whole sections of your core architecture every 3 months phase of the project, whichevery project Ive been on hasnt really left ;)   Well, it honestly does get in your way. Ive had whole teams screaming about unit testing, and ripping what was in place out, because ofthat.  Then later, a couple years later, adding it back in, slowly.   Im really big about doing just what you need, now, without putting yourself in a corner … because 2 weeks from now,youll need something completely different.  That gets back to the overengineering.  Overengineering is extra painful when you are being highly agile, and changing directions as needed.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    73. 73. “In general, I expect to see mid- level to be 2-5 or 3-6 years experience, somewhere in there.    So about a 3 year path.  Now, if the mid has 6 years experience, and still doesnt seem senior,then they could get that in a year,via expanding their horizons, Id think.”... “Of course, it alldepends on the company and the individual.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    74. 74. http://www.phpdeveloper.org Zachary Burnham Energy Federation Incorporated May 27, 2011
    75. 75. “For books, whateverbook I write next willbe a must.  Make sure you buy it.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    76. 76. “Its definitely not about hours.  Hours are a horrible measure as one coder might spend 1 hourand get more done than the guysitting in the chair for 20 hours.   So it always comes down to tasks.   Tasks are assigned, and reasonable timeframes arediscussed.   Performance is then measured by if the tasks aredone in reasonable timeframe … AND/OR if the junior comes back and says:  "Dude, we underestimated", and s/he is Zachary Burnham right :)” Energy Federation Incorporated May 27, 2011
    77. 77. “[I]t comes back to the whole get involved thing ... Community, conferences, IRC, blogs,something.   Get a greater look on life than justwhat you do at your job each day.   Of course, agood company is going to encourage you to do that as PART of your job, but not all will.  Oneother thing I might throw in there, is while you are at that mid-level … think hard about your future.   Decide where you want to be in your career, end-game wise.   If you see yourself moving into the management realm … then honestly start working towards that.   If you (Dear Disney: Please don’t sue me. Love, Zach)want to be the guy who has written code for 50years, then thats cool too, and keep focusing on that.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    78. 78. Many moons ago, at the tender age of 14, Cal touched his first computer. (We’reusing the term “computer” loosely here, it was a TRS-80 Model 1) Since then hislife has never been the same. He graduated from TRS-80s to Commodores andeventually to IBM PC’s.For the past 10 years Cal has worked with PHP and MySQL on Linux, OSX, andWindows. He has built a variety of projects ranging in size from simple web pagesto multi-million dollar web applications. When not banging his head on hismonitor, attempting a blood sacrifice to get a particular piece of code working, heenjoys building and managing development teams using his widely imitated butnever patented management style of “management by wandering around”.These days, when not working with PHP, Cal can be found working on a varietyof projects, most of which require a higher security clearance than you have sothey can’t be listed here.Cal is currently based in Nashville TN where he is currently gainfully unemployedas the Chief Marketing Officer of Blue Parabola, LLC. Zachary Burnham Energy Federation Incorporated May 27, 2011
    79. 79. Cal EvansMany moons ago, at the tender age of 14, Cal touched his first computer. (We’reusing the term “computer” loosely here, it was a TRS-80 Model 1) Since then hislife has never been the same. He graduated from TRS-80s to Commodores andeventually to IBM PC’s.For the past 10 years Cal has worked with PHP and MySQL on Linux, OSX, andWindows. He has built a variety of projects ranging in size from simple web pagesto multi-million dollar web applications. When not banging his head on hismonitor, attempting a blood sacrifice to get a particular piece of code working, heenjoys building and managing development teams using his widely imitated butnever patented management style of “management by wandering around”.These days, when not working with PHP, Cal can be found working on a varietyof projects, most of which require a higher security clearance than you have sothey can’t be listed here.Cal is currently based in Nashville TN where he is currently gainfully unemployedas the Chief Marketing Officer of Blue Parabola, LLC. Zachary Burnham Energy Federation Incorporated May 27, 2011
    80. 80. “I expect my mid-range developers to be able to code and perform like Seniors.  The onlydifference is that I expect Seniors to be able to mentor. If I dont think you can learn new technologies, pick up new techniques andbasically "figure [stuff] out" then I most likelywont hire you.” … “A Senior should be able to lead. A Mid should be able to code, a Jr. should be able to learn.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    81. 81. “You should be able to identify a problem, propose a solution, take criticism if the solution isnt the best one and then go figure out how to code it.  And by figure out I meaneither write the code or ask someoneto help. Dont stare at the screen for 4 hours and then go ask someone.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    82. 82. “Showing that I can give you a problemand 2-3 developers to work with and you solve the problem without causingpersonnel problems or causing fights gets you an interview from mid to Sr.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    83. 83. “[T]hat varies wildly with the person and thecareer goals of the person.  If they are a fantastic coder but not comfortable leading...never.  A lot of developers dont want that addedresponsibility thats fine and I reward them withraises and such just the same. But if they want to climb to Sr. and then to Architect (An architect absolutely MUST be able to inspire confidence and lead...otherwise hes useless) then I create that career path for them. Some, like me, dontwant to climb a technical ladder at all, they want to move into management. I encourage this for the right people.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    84. 84. “I dont care that youve read Tom Peters latest. I care that you took a Jr. under your wing and now Ive got 2 Mid levels. SHOW ME.  And dont do it and then expect me to see it. TELL ME. If you cant toot your own horn a bit, no one else will. Dont tell me piddly [stuff]. But when a project is done and youve helped the new Jr with his, get the Jr to tell me how much you helped. Then Ill call you both in and welldiscuss it.  Figure out how to train people.  Write blogs, host informal training lunches, step it so so that every time I turn around I am hearingyour name...oh and keep your project on track.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    85. 85. “If you are a developer then you can look at another developer, the work they did on the last sprint/project/or bug, howlong it took them and you should be able to decide if it was appropriate.  If you think it wasnt talk to them. Ask them why in a very non-threatening way.  If they are blowing smoke up your skirt, you know it because you ARE adeveloper. … I tolerate failure all the time. I wont tolerate lying to me or covering stuff up. … You cant teach a project manager how to know if a developer is lying to them. They have no frame of reference.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    86. 86. “Figure out what you want to do. Do you want to code? Do you want to manage?  Dont climb to architect level and then figure out you really wanted to manage.  Once you know,make it your passion. Figure out what the next step is either in yourcompany or in the company you want (That’s a passion fruit.) to work for and then take the step.” Zachary Burnham Energy Federation Incorporated May 27, 2011
    87. 87. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    88. 88. What have we learned? Zachary Burnham Energy Federation Incorporated May 27, 2011
    89. 89. Books:Advanced PHP Programming - Schlossnagle http://tinyurl.com/5rt3oj7The Pragmatic Programmer  - Hunt and Thomas http://tinyurl.com/6hk7plzThe Mythical Man Month - Brooks http://tinyurl.com/65upu99Code Complete 2 - McConnell http://tinyurl.com/63ex3m2The Object-Oriented Thought Process - Weisfeld http://tinyurl.com/6bsxr55Blogs:http://www.phpdeveloper.orghttp://www.planet-php.netIRCFreenode IRC network: irc.freenode.net#phpchttp://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial Zachary Burnham Energy Federation Incorporated May 27, 2011
    90. 90. Zachary BurnhamEnergy Federation Incorporated May 27, 2011
    91. 91. Zachary Burnhamzburnham@gmail.com@zburnhamhttp://www.zacharyburnham.comhttp://joind.in/3406 Zachary Burnham Energy Federation Incorporated May 27, 2011

    ×