4. So who is this guy,
anyway?
Zend Certified Engineer (5.3)
Zend Framework contributor
php|architect Technical Editor
Full 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
16. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? What was the nature of the project?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
17. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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 the
programming language in question? What was the reality?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
19. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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 the
programming language in question? What was the reality?
4. Have you ever been in a position to interview someone for a junior or mid-level
position? Recently?
4a. What questions did you ask in that interview?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
20. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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 the
programming language in question? What was the reality?
4. Have you ever been in a position to interview someone for a junior or mid-level
position? Recently?
4a. What questions did you ask in that interview?
5. If a mid-level coder came to you and asked what technologies they should
familiarize themselves 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
21. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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 the
programming language in question? What was the reality?
4. Have you ever been in a position to interview someone for a junior or mid-level
position? Recently?
4a. What questions did you ask in that interview?
5. If a mid-level coder came to you and asked what technologies they should
familiarize themselves with in order to progress to a senior level, what would you tell
them? And, why those particular technologies?
6. How long is a reasonable time-frame for a mid-level coder to become
senior, if they follow your advice?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
22. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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 the
programming language in question? What was the reality?
4. Have you ever been in a position to interview someone for a junior or mid-level
position? Recently?
4a. What questions did you ask in that interview?
5. If a mid-level coder came to you and asked what technologies they should
familiarize themselves with in order to progress to a senior level, what would you tell
them? And, why those particular technologies?
6. How long is a reasonable time-frame for a mid-level coder to become
senior, 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. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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 the
programming language in question? What was the reality?
4. Have you ever been in a position to interview someone for a junior or mid-level
position? Recently?
4a. What questions did you ask in that interview?
5. If a mid-level coder came to you and asked what technologies they should
familiarize themselves with in order to progress to a senior level, what would you tell
them? And, why those particular technologies?
6. How long is a reasonable time-frame for a mid-level coder to become
senior, 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 you're in a
position to do so?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
24. 1. Have you been in a position recently to have to orient a junior- to mid-level
developer? 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 the
programming language in question? What was the reality?
4. Have you ever been in a position to interview someone for a junior or mid-level
position? Recently?
4a. What questions did you ask in that interview?
5. If a mid-level coder came to you and asked what technologies they should
familiarize themselves with in order to progress to a senior level, what would you tell
them? And, why those particular technologies?
6. How long is a reasonable time-frame for a mid-level coder to become
senior, 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 you're in a
position to do so?
9. Any general advice that you'd give a mid-level coder? Zachary Burnham
Energy Federation Incorporated
May 27, 2011
25. IRC
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
26. IRC
Freenode IRC net work, irc.freenode.net
#phpc
http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
27. 1. Have you been in a
position recently to have to
orient a junior- to mid-level
developer? What was the
nature of the project?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
28. 1. Have you been in a
position recently to have to
orient a junior- to mid-level
developer? What was the
nature of the project?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
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. 3. What core technologies did
you 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. 4. Have you ever been in
a position to interview
someone for a junior or
mid-level position?
Recently?
4a. What questions did
you ask in that interview?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
32. 5. If a mid-level coder
came to you and asked
what technologies they
should familiarize
themselves 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. 6. How long is a reasonable
time-frame for a mid-level
coder to become senior, if they
follow your advice?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
34. 7. What resources would
you recommend? (ie
community, sites, books,
etc)
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
35. 8. How do you
measure junior coders'
productivity, if you're in
a position to do so?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
36. 9. Any general advice that
you'd give a mid-level coder?
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
37. Ben Ramsey is the Vice President of Engineering at Moontoast, the Social
Commerce Network. He is also a leader in the PHP community—the founder of
the Atlanta PHP user group, the organizer of the Nashville PHP user group, the
founder of the PHP Groups user group network, a founding member of
PHPCommunity.org, and a speaker at industry conferences worldwide.
Ben has written for php|architect, International PHP Magazine, and Zend
Developer Zone and has contributed to several books, including php|architect’s
Zend PHP 5 Certification Study Guide (Marco Tabini & Associates) and PHP 5
Unleashed (Sams).
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
38. Ben Ramsey
Ben Ramsey is the Vice President of Engineering at Moontoast, the Social
Commerce Network. He is also a leader in the PHP community—the founder of
the Atlanta PHP user group, the organizer of the Nashville PHP user group, the
founder of the PHP Groups user group network, a founding member of
PHPCommunity.org, and a speaker at industry conferences worldwide.
Ben has written for php|architect, International PHP Magazine, and Zend
Developer Zone and has contributed to several books, including php|architect’s
Zend PHP 5 Certification Study Guide (Marco Tabini & Associates) and PHP 5
Unleashed (Sams).
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
39. “I've 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. “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 that
in mind, it wasn't a destructive review,
but rather, constructive.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
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, they
will somewhat forego their "jack-of-all-trades" that
seems to come with being more of a mid-level dev.
… I think "soft skills" and leadership abilities start
becoming 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. There's 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
43. OH NOES!
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
44. “Everyone's 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. “The best senior-level developers
are the ones who strive to be the
best at what they're doing, so the
advice I would give anyone is to be
your best. That's really cheesy-
sounding, but I honestly believe it.
Strive to be your best, and it will
show. If you just sit around all day,
just getting by and never going
above and beyond, then that'll
show, too.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
46. “I never really thought of myself as working
towards being a "senior" developer. I've always
just wanted to learn and be the best I could be at
what I'm doing. In my experience, that's really the
mindset it takes. It's a journey, and I'm by no
means at the end of it. I don't think you should
wait to be the "senior" anything. Just always strive
to be better at what you do, and you'll find
yourself there. … I feel like a damned
motivational speaker now.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
47. Brian DeShong is an Atlanta-based senior
software engineer for Yahoo!. Brian has 12
years of experience in software development,
architecture, systems administration, and
technical leadership. He specializes in PHP
and open source technologies.
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
48. Brian DeShong
Brian DeShong is an Atlanta-based senior
software engineer for Yahoo!. Brian has 12
years of experience in software development,
architecture, systems administration, and
technical leadership. He specializes in PHP
and open source technologies.
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
49. “The idea was to have user experience
and design done and signed off on before
we started building a feature. It didn't
always work out perfectly, but if UX/
design was behind, we'd at least start
back end code and foundational stuff for
the component at the start of the sprint.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
51. “The types of projects I've 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. “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 rolling
your own and thinking you're smarter than the
average bear, it's better to stand on the
shoulders of giants and leverage the thinking
that's 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. “I say that's absolutely true. Leading a team, or at
least 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. “If they're looking back [at] old code and NOT
saying "what the hell was I thinking?" then that
means they're not learning and growing as a
developer.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
55. “I've seen managers promote people one level
up for a year. Those managers, frankly, are
[stuff]y and should be fired. They're doing a
HUGE 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. The Pragmatic Programmer
The Mythical Man-Month
Code Complete 2
The Object-Oriented Thought Process
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
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. “Always be enhancing your skills and
gaining more experience. It's key to growing
your career. Work with others. Question
everything. If you don't believe in
something, say so. Don't be a sheep. And
always 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. Matthew Turland has been working with PHP since
2002. He has been both an author and technical editor
for php|architect Magazine, spoken at multiple
conferences including ZendCon and php|tek, served as
an instructor for php|architect training courses, and
contributed to Zend Framework. He holds the PHP 5
and Zend Framework certifications and is the author
of 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. Matthew Turland
Matthew Turland has been working with PHP since
2002. He has been both an author and technical editor
for php|architect Magazine, spoken at multiple
conferences including ZendCon and php|tek, served as
an instructor for php|architect training courses, and
contributed to Zend Framework. He holds the PHP 5
and Zend Framework certifications and is the author
of 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. “Designing and maintaining code to be
flexible that way isn't really something
that can be taught or communicated in so
many words. So, I guess that's part of
what comes with experience. School
generally hands you requirements that
don't change. Contrasts to the real world
that way.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
63. “He's closer to mid-level now, but not
quite ready to move far outside his
comfort zone. I think to a certain
degree that that's something that
separates a mid- from a senior-level.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
64. “If someone doesn't mix well with your
team in an interview, that's a good
indicator they might not work well
together. You can teach an unskilled
developer skills. Teaching someone who's
not used to working with a team or
prefers to operate independently to work
well with one [is not as easy] in my
opinion. Being able to collaborate and
communicate are essential. A lot of times,
we're not just writing code: we're bridging
the gap between people and technology.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
65. “Your job can’t be a 9-5 if you ever hope to be truly
good 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 care
about 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 of
stopping. 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. “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. Eli has worked in/on/around the internet for over 16
years, with the last 10 spent exclusively with PHP. He
has worked a number of varied jobs in the past,
including HiiDef/Goodsie, Zend, TravelPod/
TripAdvisor, Digg and for the Hubble Space Telescope
Program. He is co-author of the book PHP 5 in
Practice and has presented at numerous conferences.
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
68. Eli White
Eli has worked in/on/around the internet for over 16
years, with the last 10 spent exclusively with PHP. He
has worked a number of varied jobs in the past,
including HiiDef/Goodsie, Zend, TravelPod/
TripAdvisor, Digg and for the Hubble Space Telescope
Program. He is co-author of the book PHP 5 in
Practice and has presented at numerous conferences.
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
69. “I've 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. “Now, of course it's 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. I've had
people come into a situation, and
immediately start ripping on the existing
codebase because it's not <insert big
name framework> … or because it
doesn't use a certain design pattern, or
because it's not using a certain templating
engine, etc.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
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 it's met. You don't need to understand
the deep core event model, or stuff like
that. Heck, I've 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. “Stuff like Unit Testing, well, dirty little secret, I've done very
little of it. Again it's been because of the nature of the projects
I 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, which
every project I've been on hasn't really left ;) Well, it honestly
does get in your way. I've had whole teams screaming about
unit testing, and ripping what was in place out, because of
that. Then later, a couple years later, adding it back in, slowly.
I'm really big about doing just what you need, now, without
putting yourself in a corner … because 2 weeks from now,
you'll 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. “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 doesn't 'seem' senior,
then they could get that in a year,
via expanding their horizons, I'd
think.”... “Of course, it all
depends on the company and the
individual.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
75. “For books, whatever
book I write next will
be a must. Make sure
you buy it.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
76. “It's definitely not about hours.
Hours are a horrible measure as
one coder might spend 1 hour
and get more done than the guy
sitting in the chair for 20 hours.
So it always comes down to
tasks. Tasks are assigned, and
reasonable timeframes are
discussed. Performance is then
measured by if the tasks are
done 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. “[I]t comes back to the whole 'get involved'
thing ... Community, conferences, IRC, blogs,
something. Get a greater look on life than just
what you do at your job each day. Of course, a
good company is going to encourage you to do
that as PART of your job, but not all will. One
other 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 50
years, then that's cool too, and keep focusing on
that.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
78. Many moons ago, at the tender age of 14, Cal touched his first computer. (We’re
using the term “computer” loosely here, it was a TRS-80 Model 1) Since then his
life has never been the same. He graduated from TRS-80s to Commodores and
eventually to IBM PC’s.
For the past 10 years Cal has worked with PHP and MySQL on Linux, OSX, and
Windows. He has built a variety of projects ranging in size from simple web pages
to multi-million dollar web applications. When not banging his head on his
monitor, attempting a blood sacrifice to get a particular piece of code working, he
enjoys building and managing development teams using his widely imitated but
never patented management style of “management by wandering around”.
These days, when not working with PHP, Cal can be found working on a variety
of projects, most of which require a higher security clearance than you have so
they can’t be listed here.
Cal is currently based in Nashville TN where he is currently gainfully unemployed
as the Chief Marketing Officer of Blue Parabola, LLC. Zachary Burnham
Energy Federation Incorporated
May 27, 2011
79. Cal Evans
Many moons ago, at the tender age of 14, Cal touched his first computer. (We’re
using the term “computer” loosely here, it was a TRS-80 Model 1) Since then his
life has never been the same. He graduated from TRS-80s to Commodores and
eventually to IBM PC’s.
For the past 10 years Cal has worked with PHP and MySQL on Linux, OSX, and
Windows. He has built a variety of projects ranging in size from simple web pages
to multi-million dollar web applications. When not banging his head on his
monitor, attempting a blood sacrifice to get a particular piece of code working, he
enjoys building and managing development teams using his widely imitated but
never patented management style of “management by wandering around”.
These days, when not working with PHP, Cal can be found working on a variety
of projects, most of which require a higher security clearance than you have so
they can’t be listed here.
Cal is currently based in Nashville TN where he is currently gainfully unemployed
as the Chief Marketing Officer of Blue Parabola, LLC. Zachary Burnham
Energy Federation Incorporated
May 27, 2011
80. “I expect my mid-range developers to be able
to code and perform like Seniors. The only
difference is that I expect Seniors to be able to
mentor. If I don't think you can learn new
technologies, pick up new techniques and
basically "figure [stuff] out" then I most likely
won't 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. “You should be able to identify a
problem, propose a solution, take
criticism if the solution isn't the best
one and then go figure out how to
code it. And by figure out I mean
either write the code or ask someone
to help. Don't stare at the screen for 4
hours and then go ask someone.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
82. “Showing that I can give you a problem
and 2-3 developers to work with and you
solve the problem without causing
personnel problems or causing fights gets
you an interview from mid to Sr.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
83. “[T]hat varies wildly with the person and the
career goals of the person. If they are a fantastic
coder but not comfortable leading...never. A lot
of developers don't want that added
responsibility that's fine and I reward them with
raises 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 he's useless) then I create
that career path for them. Some, like me, don't
want 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. “I don't care that you've read Tom Peter's latest.
I care that you took a Jr. under your wing and
now I've got 2 Mid levels. SHOW ME. And
don't do it and then expect me to see it. TELL
ME. If you can't toot your own horn a bit, no
one else will. Don't tell me piddly [stuff]. But
when a project is done and you've helped the
new Jr with his, get the Jr to tell me how much
you helped. Then I'll call you both in and we'll
discuss 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 hearing
your name...oh and keep your project on track.”
Zachary Burnham
Energy Federation Incorporated
May 27, 2011
85. “If you are a developer then you can look
at another developer, the work they did
on the last sprint/project/or bug, how
long it took them and you should be able
to decide if it was appropriate. If you
think it wasn't 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 a
developer. … I tolerate failure all the time.
I won't tolerate lying to me or covering
stuff up. … You can't 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. “Figure out what you want to do. Do
you want to code? Do you want to
manage? Don't 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 your
company 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
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&#x2019;s more than just a paycheck for them; it&#x2019;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&#x2019;s more than just a paycheck for them; it&#x2019;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&#x2019;s more than just a paycheck for them; it&#x2019;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&#x2019;s more than just a paycheck for them; it&#x2019;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&#x2019;s more than just a paycheck for them; it&#x2019;s a way of life. \n
I am not a code ninja. \n
I frequently describe my coding style as &#x201C;a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.&#x201D;\n\nI could be charitably described as a &#x201C;mid-level&#x201D; 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&#x2019;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 &#x201C;a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.&#x201D;\n\nI could be charitably described as a &#x201C;mid-level&#x201D; 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&#x2019;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 &#x201C;a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.&#x201D;\n\nI could be charitably described as a &#x201C;mid-level&#x201D; 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&#x2019;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 &#x201C;a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.&#x201D;\n\nI could be charitably described as a &#x201C;mid-level&#x201D; 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&#x2019;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 &#x201C;a deranged howler monkey on acid pounding away at a keyboard with a rubber mallet.&#x201D;\n\nI could be charitably described as a &#x201C;mid-level&#x201D; 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&#x2019;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&#x2019;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 &#x201C;senior developers&#x201D; 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 &#x2018;nearby communities&#x2019; as communities with members that overlap into the php community; In other words, some people would not define themselves primarily as &#x2018;php programmers&#x2019; 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&#x2019;re not familiar with IRC, Wikipedia has a good tutorial at http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial .)\n\nLet&#x2019;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&#x2019;re not familiar with IRC, Wikipedia has a good tutorial at http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial .)\n\nLet&#x2019;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&#x2019;re not familiar with IRC, Wikipedia has a good tutorial at http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial .)\n\nLet&#x2019;s expand on each question in turn:\n
This question was intended to determine if the senior dev had recent experience in &#x2018;handling&#x2019; 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&#x2019;s own code?\n\n
We&#x2019;ve all got bad habits. (Yes, even you.) I wanted to find out how bad they considered &#x2018;bad&#x2019;, 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&#x2019;t know the difference between Java and Javascript.)\n
Here I&#x2019;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&#x2019;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&#x2019;ll see.\n
A light at the end of the tunnel is always nice. Unless it&#x2019;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 &#x2018;becoming senior&#x2019; that could cut effort and time out of the equation. Man, for just once, couldn&#x2019;t there be some simple answers?\n
One of the ways I defined &#x2018;code ninja&#x2019; is &#x2018;produces prodigious amounts of valuable code&#x2019;. 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 &#x201C;quoted&#x201D;, 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 &#x201C;more of a legacy project&#x201D;, 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&#x2019;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&#x2019;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&#x2019;re so inclined) were extremely helpful (in fact, the word he used was &#x201C;critical&#x201D;) to the agency&#x2019;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&#x2019;s code. (I should mention here that that&#x2019;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.) &#x201C;Check your ego at the door&#x201D; 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&#x2019;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 &#x2018;nitpicky&#x2019;) was able to clean it up. &#xA0;That&#x2019;s a concrete example of someplace where a dev can improve. &#xA0;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 &#x2018;just a framework&#x2019;.) &#xA0;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. &#xA0;Developers there were encouraged to use any hardware or software tools (OS, IDE, so forth) that they were comfortable with. &#xA0;\n\nWhen a gap in knowledge was identified, a junior dev would be paired with the best senior dev for the job. &#xA0;They&#x2019;d be assigned a task and would work together on it. &#xA0;It wasn&#x2019;t formal &#x201C;pair programming&#x201D;, but the two developers would be working on the same pieces of the project. &#xA0;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. &#xA0;He did not use a script, in order to get a better feel for the person&#x2019;s personality. &#xA0;One question he would ask would be for the candidate to describe, in their own words, what they were doing at their current position. &#xA0;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. &#xA0;(Good things to bone up on if you&#x2019;re not familiar, or don&#x2019;t know them by those names.) &#xA0;He&#x2019;d then do the same with design patterns; again, if they had implemented the pattern but didn&#x2019;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 &#x2018;soft skills!&#x2019; &#xA0;Others echoed this sentiment. &#xA0;Hmm, maybe there&#x2019;s something to it... &#xA0;Ben told me a senior dev needs to be able to lead a team, directing work by &#x201C;picking the right people to do certain pieces of the project.&#x201D;. &#xA0;&#xA0;&#xA0;Not the dreaded &#x201C;manager&#x201D; word, but managing the technical issues is important. &#xA0;\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. &#xA0;&#x201C;You can specialize yourself out of a job.&#x201D; &#xA0;That being said, he indicated that skills involving scaling are definite pluses to your growth as a developer. &#xA0;Optimizing your PHP, your database queries, and using APC effectively were some particular points he touched on. &#xA0;Then the &#x201C;cloud&#x201D; was mentioned. (DRINK!) &#xA0;\n
Having some sysadmin experience is also important, according to Ben. &#xA0;Being able to work in a *NIX terminal, and having some familiarity with Amazon&#x2019;s EC2 were two things he mentioned in particular. &#xA0;\n\nWhen asked about a reasonable time-frame for &#x2018;becoming senior&#x2019;, Ben described situations in which someone had been promoted to a &#x201C;Senior&#x201D; title soley due to their time on the job. &#xA0;People felt entitled to be called &#x201C;senior&#x201D; because, for example, they had been working on a project for eight years. &#xA0;You might have the title, but unless you take the initiative to further yourself, you&#x2019;ll only be senior in title. &#xA0;It also makes changing jobs difficult, since in your current position you will have worked yourself into a nice little coding rut. &#xA0;He did mention that this doesn&#x2019;t happen much in start-ups. &#xA0;(elaborate here)\n\nWhen we talked about what resources one should use to develop, most of my interview subjects mentioned IRC. &#xA0;(I&#x2019;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.) &#xA0;Ben also mentioned going to conferences (yay!) and George Schlossnagle&#x2019;s Advanced PHP Programming. &#xA0;(insert picture of cover if available.) &#xA0;\n\nWhen asked about measuring productivity, Ben couldn&#x2019;t say he had good metrics for that, such as bugs fixed or keystrokes per day. &#xA0;(Who does that, honestly? Not anyone I want to work for, that&#x2019;s for sure.) &#xA0;Ultimately, it comes down to a subjective judgment: &#x201C;Are they getting the job done?&#x201D; &#xA0;or &#x201C;Are they slowing down the team?&#x201D; &#xA0;If not/so (that&#x2019;s awkward), then it&#x2019;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&#x2019;re not growing, or you don&#x2019;t like it, then it&#x2019;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. &#xA0;It&#x2019;s your responsibility to grow, not your employer&#x2019;s. &#xA0;\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. &#xA0;I&#x2019;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. &#xA0;This application would allow affiliates to get promotional materials, schedules, various legal agreements, and so forth, and provide information back to the network&#x2019;s home office. &#xA0;Brian was the lead on the project. &#xA0;\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&#x2019;s standards. &#xA0;Things like spacing, class, method, and variable naming standards, so forth. &#xA0;The coding style in question was described as &#x2018;ZF standards plus our custom, company-specific additions&#x2019;. &#xA0;They had tried to implement PHPCodeSniffer, but in the end were not able to, &#x201C;but not for lack of trying&#x201D;.\n\nTheme alert: The tool Brian described as most useful was the code review. &#xA0;(Groan.) &#xA0;Code reviews were conducted once or twice a week at the most, with fewer unfortunately happening in the final months of the project. &#xA0;Volume of code generated would sometimes dictate when a review happened, limited to two hours max. &#xA0;\n\nWork was conducted in two week sprints, with the goal being a feature completed in each sprint. &#xA0;Some larger features took up two to three sprints.\n
Brian was not only the leader on this project, but wrote &#x201C;a LOT&#x201D; 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. &#xA0;\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. &#xA0;We then commiserated for a few minutes on how big a PITA Zend_Form can be to work with. &#xA0;(No offense, MWOP.) &#xA0;\n\nThe new hire was not expected to be especially familiar with code reviews and/or unit testing. &#xA0;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. &#xA0;(Howler monkey joke here? &#xA0;Slide with the same picture?) &#xA0;\n\nDuring Brian&#x2019;s time at this company, he had the opportunity to interview many mid-level coders. &#xA0;I asked him what was the one thing that he saw as missing from the toolkits of those he interviewed. &#xA0;&#x201C;Definitely the experience with unit testing.&#x201D; &#xA0;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&#x2019;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. &#xA0;They would then get some take-home work if they seemed like a good fit after a phone screen. &#xA0;\n\nWe then talked about toolsets to enable progression to a senior level. &#xA0;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. &#xA0;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. &#xA0;\n\nGood software design came up as well. &#xA0;\n
(Hey, I&#x2019;m not Terry Chay, I can&#x2019;t get away with naughty words.) &#xA0;\n\nDuring the course of my interviews, a common thread was that the difference between a mid-level coder and a &#x2018;senior&#x2019; coder was that a mid-level coder can code, while a senior developer can lead. &#xA0;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: &#xA0;NOBODY can go from mid-level to senior in a year. &#xA0;It just doesn&#x2019;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. &#xA0;Also, Etsy&#x2019;s &#x201C;Code as Craft&#x201D; blog. &#xA0;And shocker, he also mentioned #phpc on IRC. &#xA0;(Yes, I&#x2019;ll put that back up at the end of the talk.)\n\nSomething else he recommended was learning a new programming language. &#xA0;He described it as useful for seeing development from other perspectives. &#xA0;&#x201C;Always be learning something new.&#x201D;\n\nWe then talked about how to measure coders&#x2019; productivity. &#xA0;Brian kept an eye on Subversion commit logs as a good indicator of what someone is generating in a given time period. &#xA0;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. &#xA0;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. &#xA0;The project was a LAMP application used by vascular surgeons for data management, accreditation and quality assurance purposes. &#xA0;The replacement had had little experience with frameworks, and Matt had started writing a new version of the application using jQuery and Zend Framework. &#xA0;The new developer had had some unfortunate experience in seeing code that was poorly designed and came from &#x201C;environments where people were very resistant to change.&#x201D; &#xA0;\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. &#xA0;Client-side code was also an issue. &#xA0;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&#x2019;d both used (mostly jQuery). &#xA0;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&#x2019;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. &#xA0;His experience had been largely on the desktop. &#xA0;\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. &#xA0;Matt agreed with me that it&#x2019;s easier to progress past a &#x2018;mid-level&#x2019; point of stagnation if you&#x2019;re working as part of a team, because you always have someone to learn from, even if they&#x2019;re not necessarily &#x2018;senior&#x2019; to you. &#xA0;\n\nWe turned then to the topic of technical interviews, and Matt expressed some dismay at the fact that he&#x2019;d never been included in an interview himself. &#xA0;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&#x2019;t experience with technologies that makes a senior-level developer, and what does is &#x201C;being able to adapt oneself to technologies outside of one&#x2019;s comfort zone, which comes from the breadth of one&#x2019;s experiences. &#xA0;To that end, experience with a variety of languages and paradigms is essential.&#x201D;\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. &#xA0;\n\nAs far as a developmental timeline was concerned, Matt said that he&#x2019;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 &#x2018;day coder&#x2019; 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 &#x2018;9-5&#x2019; mode. &#xA0;Since there was the potential for a variety of experience being gained, then one would stand a better chance of not becoming a &#x201C;day coder&#x201D;, or busting out of the role if one had fallen into the trap already. &#xA0;\n\nI asked about resources to recommend, and Matt indicated that he&#x2019;d personally stopped reading RSS feeds and the like and generally got his news through Twitter or Facebook, from coworkers, or from books. &#xA0;He recommended books from O&#x2019;Reilly, Wrox, and Apress. &#xA0;(As well as his own book, php|architect&#x2019;s Guide to Web Scraping with PHP. Ding.)\n\nAs far as measuring productivity went:\n
A final quote: &#xA0;&#x201C;We&#x2019;re all teachers and we&#x2019;re all students.&#x201D;\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&#x2019;s recent positions, he was involved in hiring, orienting, and managing junior to mid-level developers. &#xA0;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. &#xA0;All were focused on one project. &#xA0;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. &#xA0;\n\nEli mentioned &#x2018;overengineering&#x2019; as being on his list of regrettable habits he saw from the developers he oriented and managed. &#xA0;For example: &#x201C;Relying on &#x2018;tricks&#x2019; in the code, one line that does a ton of work but is mindboggling versus understandable code.&#x201D; &#xA0;He also mentioned a lack of commenting as being a pet peeve. &#xA0;He described what he called the &#x2018;ooh shiny&#x2019; 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 &#x2018;stock solutions&#x2019; rather than building something yourself, he said. &#xA0;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. &#xA0;He pointed out how lots of new web applications are heavy on the AJAX/JavaScript, and it&#x2019;s &#x201C;awkward to have someone on the team who can&#x2019;t do it at all.&#x201D; &#xA0;He pointed out that &#x2018;fix this&#x2019; tasks frequently involved both PHP and JavaScript. &#xA0;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&#x2019;d been involved in hiring new developers. &#xA0;He expressed some dismay at the quality of candidates that had come from either Monster.com or outside recruiters. &#xA0;He had found better luck with candidates that &#x2018;knew someone who knew someone&#x2019;, or had reached out to a company and said &#x201C;I want to work for you.&#x201D; &#xA0;He also expressed some frustration at developers that didn&#x2019;t seem to be PHP developers so much as developers that only worked with certain frameworks. &#xA0;\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. &#xA0;He&#x2019;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. &#xA0;This seemed to avoid what he called &#x2018;test panic&#x2019; on the part of the candidate; some people who are awesome coders would not make it past that kind of interview. &#xA0;He&#x2019;d have rather discussed the resulting code in terms of &#x2018;Why did you do X&#x2019; or &#x2018;What about Y?&#x2019; or &#x2018;Look, you have a security hole here, can you explain it?&#x2019; &#xA0;Also evaluating how complex the application is to perform what is essentially a simple task was a tool he employed. &#xA0;\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&#x2019;t a technologies thing, it was an experience thing. &#xA0;In a mid-to-senior transition, he expected to see people getting involved outside of work. &#xA0;For example, attending conferences (and maybe trying to speak at one), getting involved in user groups, blogging, so forth. &#xA0;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. &#xA0;\n\nEli gave a big &#x201C;it depends&#x201D; answer when asked about a time frame to transition from mid-level to senior. &#xA0;\n
Community was the biggest thing he mentioned when asked about resources to tap into. &#xA0;He suggested local user groups, conferences, and IRC as being good examples of how to get involved in the community. &#xA0;As far as sites went, he described phpdeveloper.org as being a good place to share &#x201C;the 'cool' around the web of PHP.&#x201D; &#xA0;\n
\n
Task completion was the most important thing Eli described when asked about how to measure a coder&#x2019;s productivity. &#xA0;\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&#x2019;t recently had occasion to orient one. &#xA0;\n
Cal expects his mid-level coders to be masters at the language in question. &#xA0;\n
Cal is also of the opinion that it&#x2019;s not use of particular technologies that will enable you to make the transition from mid-level to senior. &#xA0;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 &#x2018;soft skills&#x2019;. &#xA0;In other words, if you don&#x2019;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. &#xA0;Asked about a time-frame, Cal answered thusly:\n
Food for thought, maybe? &#xA0;It seems like at the point at which you call yourself &#x2018;mid-level&#x2019;, you have a few paths open to you. &#xA0;If you don&#x2019;t see yourself coding forever, and you&#x2019;d like to work with people more, then management is an option. &#xA0;Personally, I&#x2019;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&#x2019;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&#x2019;s performance and productivity. &#xA0;Cal expressed a belief that nobody should manage software developers that hasn&#x2019;t been a developer themselves. &#xA0;\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&#xA0;&#xA0;&#xA0; Managing?\n&#xA0;&#xA0;&#xA0; Coding?\n&#xA0;&#xA0;&#xA0; Other paths?\n\nMentoring GOOD\n\nBad habits to break:\n&#xA0;&#xA0;&#xA0; Inconsistent code style\n&#xA0;&#xA0;&#xA0; Poor documentation\n&#xA0;&#xA0;&#xA0; Overengineering\n&#xA0;&#xA0;&#xA0; Reliance on a particular framework as opposed to &#x201C;raw coding&#x201D;\n&#xA0;&#xA0;&#xA0; &#x201C;Hackish&#x201D; approaches to problem solving without a deeper understanding of what&#x2019;s really &#xA0;&#xA0;&#xA0; &#xA0;&#xA0;&#xA0; going on in the code\n\nCode reviews are a useful tool to improve your code (style and content) and coding habits\n&#xA0;&#xA0;&#xA0; 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&#x2019;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 &#x201C;comfort zone&#x201D;\nGetting involved outside of work\n\nScaling skills important\n&#xA0;&#xA0;&#xA0; Memcached\n&#xA0;&#xA0;&#xA0; *nix terminal\n&#xA0;&#xA0;&#xA0; DB caching\n\nWorking as part of a team makes things a little easier\n&#xA0;&#xA0;&#xA0; \n\nTime frame\n&#xA0;&#xA0;&#xA0; &#x201C;Soft&#x201D; time frame\n&#xA0;&#xA0;&#xA0; Anywhere from 2 to 6 years\n&#xA0;&#xA0;&#xA0; Never get there if you only code &#x2018;9 to 5&#x2019;\n
