Saturday, 7 September, 2013 —
work
engineering
career
It’s entirely possible that you’re thrilled to bits with your current gig. You haven’t seen the need to update your résumé in months or years. So, I totally get it when I tell you to assemble a portfolio and you respond with, “I’m happy, I’m not going anywhere anytime soon.” Build a portfolio anyway.
In my last piece, I talked about avoiding career stagnation and working where your work is valued. Building and maintaining a portfolio is an insurance policy against stagnation and the “go bag” for your career.
Background
There’s plenty out there on programming interview questions and answers, so I’m bypassing that. Same with résumés and cover letters. I don’t see many candidates with a portfolio of past work, so that’s why I’m telling you to have one. You will automatically stand apart.
Recommending a candidate for interview or hire is a lot easier when I see how that candidate approaches problems. Onsite interviews covering design exercises and problem solving cover some of this. A take-home exercise might cover another. However, that’s still oftentimes a hint at direction than true comfort. The interview itself relies on candidates telling an interviewer a story (and make no mistake, I want to hear how you explain how you did something.) Still, four or five hours of conversation with a group of hiring managers or potential peers is barely enough time for them to reach a very solid opinion of you.
A portfolio brings an entire other dimension to bear. I get a feel how you write code completely outside the context of the interview process. I see how you think through solving a problem with design, how you model a domain. It’s a window into how you think.
What’s in your portfolio
There should be some manner of map to what’s in the portfolio. Let’s first stipulate this portfolio is online and publicly available. What I would like is a straight-ahead path to get there. Ideally, it’s a simple, direct URL. So, let’s also stipulate I’m looking at an index page that gives me a brief amount of information about you and pointers to more (a blog, Twitter, etc) and the main body of the portfolio itself. The number of items on the portfolio isn’t particularly important past there being more than one or two things there and not seeing absolutely everything you’ve ever created a repository for. Select for breadth or depth, but know what you’re deciding and why.
I would love to see a mix of complete projects, pull requests for other projects, bug reports and even some toy code. That’s strictly what I’d be most comfortable with. Vary as you like and believe you can articulate well. Choose what best demonstrates your goals and practices.
For complete projects, a README describing the project’s purpose, installation process, support and contribution practices are the first thing I’ll read. Before I read any code, I’ll try to install it. Then, I’ll probably dive into the code structure itself. Can I make sense of how the code is structured? Is it structured how I’d expect to see other code in the same language? From there, I’ll likely dive into individual files to get an understanding of classes, frameworks and so on in use. After that, I’m going to read your commit messages. How do you work with source control? I’m looking for commits that explain the why behind the what. I’m also going to take note of whether or not your project has documentation, how your code is commented or not and your code style. There’s no one right or wrong thing with these. I do like to see consistency, clarity and readability.
Pull requests are a little different. I presume there’s an originating issue I can look at to see how you interacted with the project in question, in either opening the issue or proposing a solution with the pull request. If the project initially turned down or requested changes in your pull request, how did you handle that?
Toy code is great to show how you might address a problem like FizzBuzz, practice code kata, try out different sorting algorithms or learn a new language, to name some possibilities. I get a sense of how you play to learn.
Now, here’s what I care less about, what language you write code in. Sure, I can map your experience to mine easier if I’m familiar with the language you work in and it’s one you’d be working with for the position you’re being considered for. At the same time, I care more about how I see you work on your project and how you organize it. I care more if I see experience in one language that I expect you can apply to a cousin.
Work vs. personal projects
Tricky, tricky. Generally speaking, what you write at your day job is work-for-hire and code you don’t own. Businesses are understandably touchy about having processes and methods around the core of a product out in the wild. Still, it’s nice to have something to share. So, get creative. Is there anything your shop has done that’s in support of your product, but isn’t actually your product? “Sell it” by open sourcing it. You’ll need your boss and fellow engineers to support making a case to open source a project or tool to the business. What is that case? Well, consider that lots of engineers are attracted to work at places that contribute back to the sorts of open source communities they build their products on. Engineers like you. There’s more to this than what I’ve covered. Do your research, be willing to support it vs. publishing abandonware. Still, it’s a way of liberating some code for a portfolio.
Short of open sourcing an entire tool, see if you can publish some samples. Ask. Be clear that you’re publishing when asking.
Failing that, isn’t there some itch you’ve been meaning to scratch with a project of your own? It doesn’t have to be a 25 model domain. Pick a small problem, solve it in a way you want to see solved and publish. Get feedback and iterate.
Parting thoughts
A portfolio is one piece of many that’ll be considered in a hiring decision. They’re put together and refined over months and years. New pieces are added and others removed as you learn and evolve over the course of a career. A portfolio separates you from other candidates. Again, not many people submit any code samples, let alone with any sort of considered structure. Your portfolio is a vehicle to tell a story about you and your career.
A good portfolio may not get you hired at any particular job. Instead, maintaining a portfolio is you always preparing for your next gig, even when you aren’t actively looking for it. That greatly increases the chances of landing a gig that’s worthy of you. Fortune favors the prepared.
Monday, 19 August, 2013 —
work
engineering
career
The saddest thing I’ve seen in the last few years of interviewing software engineering candidates is that a fair amount end up in career dead ends. They work for the wrong sort of company, they’re trying to get out and they’re struggling because they’re unprepared to be most anywhere else.
There are two major classes of employer I see this career anti-pattern in. First are places like banks or other large institutions where software is some manner of back office function. The second is the small “cowboy” shop where “there’s no time” for doing things the, “right way.”
What does the anti-pattern look like? There are a few tells:
First, the organization/boss can’t abide anything other than the briefest of manual testing. Unit testing, functional testing, an agile validation and verification effort or a waterfall pass through a separate QA group are all “too much” or unheard of or seen as unnecessary.
Second, the developer is solving the same problem, the same way year after year. Business runs in cycles. At the same time, if this August is the same as August last year and August two or more years ago, watch out. Quite likely, the business is ignoring or simply unaware of something that could be better.
Third, the developer works on their own or with an equally inexperienced coworker. But it’s really not pair programming or XP. It’s just two developers working in separate silos that don’t talk to each other. All of the other engineers may have been around the block a few times, some more than others, but no one has left the neighborhood in years. This ties back to the point above. If no one is seeing anything new, no one has anything new to bring to the team and everyone stagnates together.
Fourth, there are no consistent development practices like code review. Continuous integration is still magic to a lot of folks. Depressingly, source control that everyone on the team uses at all, let alone with a consistent approach, is far from universal, too. No project or prototype is too small for ‘git init’.
There are plenty of other smells, but those four are scary enough to start with.
Now, for the sake of discussion, let’s stipulate that you have a friend about whom you’re concerned because you recognize this friend’s job hits this group of smells and your friend is casting about for a new gig and not getting anywhere.
First, just because writing software for a company or a contract hits one or more of these anti-pattern points doesn’t make them bad people or a bad employer. This is orthogonal to all of that. Jobs are scarce, everyone’s circumstances are different and, as a profession, we’re really, really lucky. That said, what’s going to help keep your friend’s skills relevant? Let’s start with a harsh gate.
Avoid companies that don’t understand what it is your friend does, why they hired your friend and thereby, what your friend’s value to the organization is. A lot of times, your friend will need to talk to others, like their hiring manager, about whether or not the company understands what it is they need. If they don’t, your friend has two options. Try to educate them or find another job. The first option sometimes works, your friend shouldn’t be shy about trying it. Yet, if your friend is months into a gig and it still isn’t clear to everyone what what your friend’s value is, advise your friend to move on.
Avoid companies that don’t support good engineering practices. If this is your friend’s first engineering position, please understand your friend is at a disadvantage for being persuasive about good engineering practices. If your friend knows what good practices are and can’t convince the business to adopt them, your friend should move on.
The key for your friend is finding a gig that values that friend’s craft and the standards and practices of that craft. Software engineering is a diverse field, so it’s quite possible people in different areas of the field are going to have different definitions. But, I’ll assert the following:
- Everyone, individually, needs to be the most passionate advocate for their own career
- Everyone, individually, needs to stay abreast of what is going on in their chosen field
- Everyone, individually, needs to practice the skills that will help get them to where they want to go
- A company, or at worst, a hiring manager, should understand why they are hiring a developer and how that developer’s practices contribute to the value the developer brings to the company.
Further, developers understanding the following things have a definite advantage over developers who do not:
- Pair programming
- Continuous Integration
- The Gang of Four Design Patterns (even if you aren’t working in Java or C)
- Behavior or Test Driven Development
- Software deployment methodologies
This is beyond just having knowledge of languages and algorithms. It’s knowing and understanding how our peer group works.
Now, your friend? What might you tell this friend, in terms of improving their situation? There are two books I recommend starting with to kickstart thinking through software development practices and career development. They are, The Pragmatic Programmer by Dave Thomas and Andy Hunt and The Passionate Programmer by Chad Fowler. They are my go-to “kickstart someone’s career” books.
Above all else, your friend has to value their work and their skills to match well with an employer who respects what they bring to the table and what supports those skills. The same goes for you, too.
Tuesday, 11 June, 2013 —
apple
At WWDC this week, Apple announced a shift from naming OS X versions after big cats as has been custom since 10.0, although the naming wasn’t public until 10.2 “Jaguar.”
Now, Apple is apparently using California for inspiration with naming OS X “for the next 10 years” starting with Mavericks.
So, if I were naming future releases, what might I also use:
- Golden Gate
- Tahoe
- Joshua Tree
- Big Sur
- Sequoia
- Half Dome
- Sonoma
- Shasta
- Morro Bay
Some names I don’t expect to see:
- Bay Bridge Toll Plaza
- Richmond Refinery
- Rancho Seco
- Folsom State Prison
- Frisco
- Santa Monica Freeway
Sunday, 19 May, 2013 —
civics
barcamprdu
conference
Above: Cristóbal Palmer, Justis Peters and Dan Sterling open BarCampRDU 2013
May 18, 2013 marked the return of BarCampRDU after an 18-month absence. There were five session slots followed by lightning talks. All the sessions I attended were in some way interesting (see below for a list), but I want to start by focusing on one by Jason Hibbets, “Open Source All the Cities!”.
Overall, I was impressed at Hibbets’ passion for civic involvement. I was also pleasantly surprised by the number of Open Data/Open Government initiatives already in-progress in Raleigh. It’s something I’ve had a desire to see and participate in, but did not know was thriving. In particular, I’ll be making use of SeeClickFix to request some traffic calming in my neighborhood. I also want to have a look through Raleigh’s open data portal to see what I can pull out and futz with.
For as much as government is complained about, a lot of time, it’s just “there” for a lot of folks. I don’t know if there was ever a golden age of civic involvement, but I hypothesize that we have better neighborhoods and cities if we learn more about how to affect change in our neighborhood and follow-up on it. What I mean by that is making sure problems with infrastructure are reported, instead of assuming someone in Public Works knows. It means asking for sidewalks, crosswalks and traffic calming to help neighborhoods more walkable. It means reporting problem properties, starting a neighborhood watch, having a block party, cleaning a neighborhood creek or just clearing the storm drains down the block.
These aren’t partisan issues. Think of civics as a sense of stewardship for what’s around you. I am a steward, my neighbors are stewards, if they choose to be, city government is a stewardship, too, and one that I can influence. You can, too.
My raw notes for Jason’s talk:
- Explaining open source to a non-technical/unfamiliar audience
- Open source is like a recipe
- Principles
- Transparency
- Code
- Roadmaps
- Bug reports
- Creates accountability
- Collaboration
- Hierarchy vs. peer-to-peer
- Foster innovative ideas
- Rapid prototyping
- Release early, release often
- Fail faster
- Meritocracy
- Best ideas rise to the top
- Passion
- Projects exist because people are trying to scratch their own itch
- Open source as a philosophy past software engineering
- opensource.com is where discussion happens about things that can have open source principles applied to other areas
- Civics beyond government
- Opening up a channel back to government
- Creating a community
- Elements of a open source city
- Culture/participation
- Open government and data policies
- Catalyst: CityCamp Raleigh
- 200 people each of the last two years
- Triangle Wiki
- Had a Triangle Wiki Day
- 50 people showed up including city council members, mayor
- RGreenway team built the RGreenway mobile app
- Goal is to do something after the Camp
- CityShape – Mayor’s Challenge
- “Where should we put more density?”
- SeeClickFix
- Bug tracking for city infrastructure
- Potholes
- Tree branches
- Graffiti
- During Hurricane Sandy, people used the tool to organize + source help
- Bonner Gaylord
- Open Gov advocate and city councilman
- Piloted in his district and city council ended up adopting
- Goal is to break down political boundary barriers (e.g. Raleigh and Cary)
- You can set-up watch areas to see when other people submit items in your area
- City council, mayor and local media all get pinged when an item gets submitted
- Open government resolution
- City of Raleigh will consider open source software
- Established an open data portal
- City put $50,000 and hired an open data manager toward that initiative
- Open Raleigh website
- Data Portal
- Code for America
- Peace Corps for Geeks
- Built “Adopt a Fire Hydrant” for Boston
- Other “Adopta” solutions
- Sidewalks in Chicago
- Bus stops in Raleigh
- Storm drains in Seattle
- Tsunami Sirens in Honolulu
- Brigade program
- Code for Raleigh
- Active
- Participated in “Race for Reuse”
- We already have applications that are good, how can we increase their adoption?
- Cary just adopted a brigade
- Durham is close to having one
- Proposed: Triangle Code for America Division
- Get multiple brigades together to share expertise
- He wrote a book, The Foundation for an Open Source City
- Get involved!
Other sessions
The other sessions I attended were:
- Organizing Tech. Conferences
- BarCampRDU 2013 organizer Jeremy Davis led a retrospective on the organization of BarCampRDU 2013 and the elements that make a technical conference successful
- Worth a post on its own
- Git Internals
- Jimmy Thrasher did a nice whiteboard session of how Git does what it does
- Getting Kanban-odoros Done!
- Chris Imershein led a session talking high level about
- Getting Things Done
- Personal Kanban
- The Pomodoro Technique
- Pebble API
- Lightning Talks
- There were several, but two in particular I liked.
- Justis Peters talking about several Coursera courses he is taken or has taken around machine learning and neuroscience
- A talk on the value of full-spectrum lighting (if someone can tell me the name of the woman who presented that, I would love to update the post accordingly)
Event photos
I took a few. Check out the set I put together over on Flickr.
Thank you
The BarCampRDU 2013 organizing group and volunteers did a fantastic job with the event. Thank you, all, for your efforts in rebooting the event. Having BarCampRDU back is great for the local community. Thank you, too, sponsors.
I’m looking forward to BarCampRDU 2014.
Tuesday, 26 February, 2013 —
devops
Asking “What is DevOps?” is a question I’ve heard some variation on frequently over the last couple of years as it’s blown-up as a career niche. There’s been a counter-movement. DevOps as a term is about as well-defined as Agile is for software development, which brings me directly to my point.
There’s what engineers I work with call “Capital A Agile.” Think dogmatic practice of Scrum, where absolutely everything has been processed out to the hilt:
- Sprints are always n weeks
- Releases are always n sprints
- Sprint teams always have n Engineers and int(n/2) QA Analysts
- The retrospective is always at 3 pm on the Monday after the sprint finished
Process isn’t bad. Defining process is great and on the whole, having guidelines similar to the four above is healthy. What’s less healthy is the word always in each of these. Capital A Agile is a process smell, particularly when additional rules get layered on regarding grooming sessions, and so on.
Conversely, “little a agile,” will probably have less strict process definition:
- Sprints last two weeks
- Releases are two sprints
- We aim to have teams of four to six engineers and two to three QA analysts
- Our standing meetings are …
- All points are renegotiable when the need to be
Keeping with the sprit of the Agile Manifesto, process is important, but not as important as healthy interactions within the team.
To that end, think of Scrum and Kanban as process and planning design patterns. Just as it isn’t smart to force an inappropriate design pattern where it shouldn’t be in software, it’s not smart to force more process than the team requires to deliver what the business needs.
How does this relate to DevOps? Just as Agile practices within a company can ossify, so too can DevOps. Think instead of little d devops, loosely-coupled and evolving best practices for getting developers to think of software all the way through production, indeed of deploying to production as a beginning and systems administrators and infrastructure engineers facilitating an entire team to be able to own what ships, how it ships and how it lives once shipped.