In doing this, I’ve learned a ton about building well-documented open source projects, collaborating with other devs remotely, and I’ve forced myself to come up with ideas to use my own open source projects. The latest, JobsToMail just came out a few weeks ago and has already attracted more interest on Github than any of my other open source projects…not that that’s saying much.

More than anything though, this has been a really great learning process for me as a developer and architect. I’ve gotten to experiment with new things that wouldn’t have been practical to explore at work, and it’s made me more confident in putting my code out in the public than before.

Read more about the open job board API project at JobApis.com.

I’ve been working on several open source packages for both the JobApis project as well as a couple small projects for my team at The Graide Network in the past few months, and it’s gotten me thinking about what a good open source PHP project needs. A project with great, clean, readable code is nice, but it’s not really usable without all the other things that make a good open source project including tests, documentation, a license, etc.

I would love to get feedback on this list from other devs, and I have to pass along credit for the ideas here. I learned about most of these items from PHP packages created by the PHP League and my friend (and League member) Steven Maguire. From my experience working with several open source packages, contributing to a few, and creating several, here’s the list of things I have found most important when creating a high quality open source PHP project:

1. Host the repository on Github

I’ve been using Bitbucket at The Graide Network, but I have to say Github is far superior for open source projects.

2. Write a quality Readme.md file

There are a lot of great Readme file examples out there, but I like to include the following sections on my projects:

• Intro
• Badges
• Installation instructions
• Usage/examples
• Testing policy/instructions
• Links to a contributing.md, license.md, and changelog.md file

3. Include a Changelog.md file

The Changelog file is a short summary of the updates made in every version released. Use semantic versioning (see below), and if you’ve never written a changelog, here’s a great example of one. Make sure you update this file for every release. It’s easy to forget until it becomes a habit.

4. Document guidelines for contributing

I like using a Contributing.md file so that Github shows it to people when they create issues or pull requests. Here’s a good example from the PHP League.

5. Choose an open source license

This usually seems unimportant for brand new packages, but as soon as your project gains some traction, it’s a huge deal. Companies using your project may or may not be able to depending on the license you choose. Here’s a no BS comparison of popular open source licenses.

6. Add a code Linter, check for PSR standards

Squizlabs has an excellent code sniffer that will let you check your code against PSR-2 (and other) standards sets. This is really helpful once you have a few contributors and each may have their IDE set up differently. Tabs vs. spaces is a real debate.

7. Write unit and integration tests

If you haven’t gotten to write many tests in your projects at work then open source projects is a great time to get introduced to testing in PHP development. I’ve written a bit about testing before, but take my word, it’s important and will save you a ton of headaches in the long-term.

8. Use Travis and Scrutinizer

The pairing of Travis-ci and Scrutinizer-ci allows you to run your open source project’s tests and get a code quality score for free. This stuff would cost hundreds of dollars per month on closed-source software, so it’s awesome to take advantage of these tools on your open source projects for free. Here’s a tutorial on why and how you can set Travis and Scrutinizer up.

9. Include a composer.json file, release the project on Packagist

For some reason a lot of good PHP developers I know are intimidated by releasing their open source projects on Packagist, but Composer is the standard in PHP package management, so it’s really helpful for gaining users. It takes about 15 minutes to release your first package (maybe less if you’re a fast typer), so don’t fear it.

10. Use semantic versioning and Github’s release tags

Semantic versioning is another great tool for open source developers. If done correctly, it shows users of your package how stable the project is, whether or not updates will break their system, and lets them set rules about when to update or not update the project.

Semver works nicely with git tags which are reflected in Githubs “release tags” feature. I like to copy the lines from the Changelog into my Github tag body as you can see in the jobs-common project.

11. Create and label some issues

I like to create a few known issues in any new open source repository. Even if a project is brand new and seems to work perfectly, there’s probably room to improve test coverage, documentation, or enhance it with new features. Repositories with a few open Github issues look more active and give new potential contributors a place to start.

12. Respond to contributors

My biggest pet-peeve when contributing to open source projects is unresponsiveness. I get that you may be too busy to review every PR within hours, but simply responding and letting people know you’re considering their pull request is rude and makes your project look abandoned.

Finally, I’d encourage you to check out the PHP League’s skeleton project, which they use as a base for all their open source packages. If you’ve never started your own open source project before this is a great place to start. Also, if you’d like a printable version of this checklist, click here.

If you have items that you’d add to this checklist, let me know. I’m always open to new conversations on Twitter or via email.

One of the most interesting trends is the rise of “smart” messaging platforms, which allow participants to do more than just send text across a network. They allow for rich text, animated gifs, videos, sound-bites, and links to be sent in real time to one or more participants in the chat. This alone isn’t really new (AIM had a lot of this stuff a decade ago), but one thing that has changed is the speed and availability of these methods of communication.

The other thing that has changed is the “smartness” of the servers relaying these messages, and that’s where messaging as a platform begins.

What does “messaging as a platform” mean?

The term “___ as a platform” can apply to many things in our digital world. In the development community, we call services that allow us to host our code “infrastructure as a platform” (or “infrastructure as a service”) because while there is infrastructure out there in the cloud, we only care about the platform that it allows us to build on.

Messaging as a platform is more analogous to something like a “website as a platform,” so let’s follow this analogy:

In a traditional website, forms are used to handle input from users. For example, when you want to sign up for a service, you put your email address and name into a form and then click submit. This triggers a bunch of stuff on the backend to register your account and show you a confirmation page.

Meanwhile if you used a messaging app as a signup medium, you might text your email address to a specific phone number and then their service will automatically text you back a confirmation. The messaging system you used (eg: SMS, Facebook, Slack) was the platform that kicked off your signup – something that has traditionally been done via the web or a smartphone app.

What are some possible uses for message-driven platforms?

So messaging as a platform is becoming increasingly popular as messaging apps become more popular, but in my example above it’s hard to see the real advantage of having users text you their email instead of just filling in a form online. On the other side, it’s hard to see the advantage as a user because signing up might get you the same content regardless of whether you sign up via a web form or text message.

Let’s look at some messaging platforms and the ways that various people are using them today.

Slack bots – Slack has hung their hat on the ease and accessibility for developers to create bots. This community of slackbot creators has released hundreds of open source bots that automate everything from the mundane to the extremely complex and allow Slack users to do all sorts of things without leaving Slack’s platform.

Intercom – While Slack has become the go-to inter-team communication platform, Intercom has placed itself as the leader in sales and customer service chats for businesses. They have a platform that allows users on any website to chat directly with real humans who work there, asking questions or getting clarification before they sign up. Similarly, you can automate Intercom to proactively message users as they come to certain pages or enter specific inputs.

Twitter auto-DMs – I’m sure the first marketers who discovered that you could automatically send direct messages to new followers had good intentions, but the automatic DM has been misused and abused. That said, Twitter is being used as an automated messaging platform for a few interesting cases.

Using Facebook messenger to order pizza – Facebook opened up its messaging platform to bots earlier this year and since then several companies have taken advantage of the platform’s ability to take payments and interact with customers. Domino’s now allows you to order pizza via Facebook messenger.

Google search results in a conversation – Google just released Allo, a messaging service that integrates with its search platform to allow chatters to search for things within a conversation. The implication here is that you could be talking with a friend about getting dinner and then use Allo to look for restaurants right in the middle of your conversation. For Google, the conversation is an interesting point for context, and I can imagine them showing different results based on the preferences of both parties rather than simply showing the best result for the asker.

Real time, on demand stock quotes – This has been around for a long time, but it’s worth including as a simple example of messaging as a service. You can sign up to receive stock quote alerts for specific companies or industries via a service like Zignals.

Arbitrary tasks or questions (eg: Siri, Amazon Echo) – Messaging platforms have moved beyond text, and one of the next frontiers seems to be spoken word. Apple, Google, Microsoft, and Amazon have voice-activated personal assistants that allow users to ask arbitrary questions or do simple tasks like create emails or calendar events. While few of these platforms are deeply integrated into third party services at this point, I’d bet that’s coming soon.

Twilio for creating messaging services via SMS – Finally, Twilio has spent the past 8 years making SMS text messaging a more accessible platform for developers to create their own text bots or services. Using Twilio’s tools, you can make bots, send alerts, broker communication between anonymous users, and much more.

WeChat allowing creation of apps within its chat app – WeChat might not be a familiar name to us in America, but as the dominant Chinese messaging platform it influences a huge portion of the world’s population. They are now allowing users to create “little programs” or apps within their chat application. I have yet to see an example of something created within WeChat, but keep an eye out for this very soon.

Why does this matter?

A decade ago, the prevailing wisdom was that your company needed a website. A couple years later it was a social media page, and now it’s an app. It’s not hard to imagine a future where chat becomes an essential marketing channel.

In the short-term, we’re seeing cutting edge companies use chat to rebuild existing applications, but I think that in the long-term certain applications will cease to exist elsewhere. Is there a need for every service to have a full-featured web or mobile application? Or, could a messaging app serve its customers just as well?

At the same time, I realize that not every service will be served by messaging platforms. I don’t think you’ll be texting future employers your resume (although maybe I’m wrong), but I could see a world where I don’t have to log into Jimmy John’s website just to order a sandwich.

What do you think? Have you seen any novel uses of messaging as a platform? Where do you see the trend going? Let me hear about it on Twitter.

Another thing I’ve noticed lately is that I don’t want to check 100 different sites every day for information. For example, I subscribe to about 300 engineering blogs, but there’s no way I want to go check every one of those websites every day. I use a Feedly collection and IFTTT to email myself a daily summary of all the new articles posted, and this works really well for keeping me informed with a minimal amount of effort.

Job board search as a service

My system for keeping up with engineering blogs got me thinking: what if I could help job seekers keep up with dozens of job boards by sending them a single simple email every day?

I’ve been maintaining the JobApis project (formerly JobBrander) for a few years now, so I’ve gathered a lot of knowledge and created many open source clients for job boards. A job board to email project would be a great way to combine my knowledge with something that might actually be useful.

So I released JobsToMail as an open source project and free service this weekend.

How JobsToMail Works

The goal of JobsToMail is to create a personal assistant for job seekers. People looking for jobs should be out there meeting people, doing interviews, coffee chats, etc, and not spending all day trolling job boards. JobsToMail saves you time by looking for new jobs every day on several major job boards and then sending the results to you in a single email.

Under the hood I’m using the Jobs Common and Jobs Multi projects to interface with 6 job board APIs with plans to support many more in the future. If you want to get even more technical, read on.

Collecting and emailing jobs

The signup process is a very simple form submit where the user submits their email, search term, and location. This triggers an email to the user with a confirmation link. Once clicked, that link will “confirm” the user’s email and the user will start to receive an email every day.

I’m currently hosting the project on Heroku and using their Postgres and Scheduler add-ons to handle the database, queuing, and cron jobs. The reason I went with Heroku was for ease of setup and deployment. I’d like people who want to host their own version of the project to be able to easily setup the application, and Heroku is one of the easiest ways to deploy an application as a single developer.

Heroku Scheduler kicks off an artisan command (I’m using Laravel 5.3 and PHP 7 for the project) which in turn queues up a job for each user in the system to collect and email them jobs. With a small userbase, iterating through all users is not a problem, but I may have to make this more robust if I get a lot of signups someday.

Each job is processed asynchronously by Laravel’s job/event handler system, which is one of the handiest features in the framework. Each job goes to each job board and gets a collection of jobs then all the collections are sorted and an email is queued up for the user. This part takes several seconds, but if it hangs for any reason, jobs are retried a few times before being thrown into a “failed_jobs” table.

Finally, I’m using Laravel’s new Notification feature to send an email to the user who requested it. In production I’m relying on Sendgrid to send the emails as Heroku doesn’t support SMTP or PHP’s mail function.

Finally, each email that is sent includes an unsubscribe link that is unique to each user. When visited, the unsubscribe URL immediately removes the user from our distribution list so they will no longer receive emails for that search.

Where is JobsToMail going next?

Long-term my goal is to continue making JobsToMail a more valuable service to job seekers and hopefully a more accessible project to future open source contributors. There are also a lot of “obvious” features that I chose to left out in the interest of keeping the MVP lean, but hopefully users will give me some feedback for where to take the project next.

So, if you’re interested in trying it out, go to www.jobstomail.com and don’t forget to submit your ideas for improving the project on Github or to me directly on Twitter.

Highly recommended

Peopleware: Productive Projects and Teams by Tom DeMarco

The nice thing about software is that it is predictable. Computers do what you expect them to every single time, but figuring out how to make people work together is a lifelong exercise. Peopleware has helped me on my journey to figuring that out.

I wrote a more detailed review of Peopleware back in 2015. Click here for more.

Building Great Software Engineering Teams by Josh Tyler

“The challenge of scaling up a team can be intimidating…Josh Tyler has spent nearly a decade building teams in high-growth startups [most recently at Course Hero]…He draws on this experience to outline specific, detailed solutions augmented by instructive stories.”

The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt

“The Goal is a gripping, fast-paced business novel about overcoming the barriers to making money. You will learn the fundamentals of identifying and solving the problems created by constraints. From the moment you finish the book you will be able to start successfully addressing chronic productivity and quality problems.”

The Mythical Man-Month by Frederick P. Brooks Jr.

“Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects.”

Startup Engineering Management by Piaw Na

This book covers a variety of engineering topics for managers including:

• Why a manager should consider doing management work.
• How a manager should put together his team.
• The important things to consider when interacting with engineers.
• How to hire top engineers for your startup.
• How to pick engineering leaders.
• How to define processes and when don’t you need them.

The Checklist Manifesto by Atul Gawande

“The volume and complexity of knowledge today has exceeded our ability as individuals to properly deliver it to people—consistently, correctly, safely. We train longer, specialize more, use ever-advancing technologies, and still we fail. Atul Gawande makes a compelling argument that we can do better, using the simplest of methods: the checklist.”

How to Win Friends and Influence People by Dale Carnegie

“This grandfather of all people-skills books was first published in 1937. It was an overnight hit, eventually selling 15 million copies. How to Win Friends and Influence People is just as useful today as it was when it was first published, because Dale Carnegie had an understanding of human nature that will never be outdated.”

Good reads

Most of these were really good books, but they just don’t relate quite as directly to engineering management. Still worth looking into if you’re interested in software engineering, startups, leadership, and other related topics.

The Lean Startup by Eric Ries

What Color is Your Parachute? by Richard N. Bolles

How to Fail at Almost Everything and Still Win Big by Scott Adams

The Decision Maker by Dennis Bakke

Disrupted: My Misadventure in the Start-Up Bubble by Dan Lyons

Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin

Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin

The Innovator’s Dilemma by Clayton M. Christensen

Next on my list

I’ll try to remember to update these as I read through them, but here are some of the books next on my reading list.

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco

The 4 Disciplines of Execution by Sean Covey

Turn the Ship Around: A True Story of Turning Followers into Leaders by L. David Marquet

How to Make Sense of Any Mess: Information Architecture for Everybody by Abby Covert

If you have other books that I should put on my reading list, let me hear about them on Twitter.

The goal of Jobs Common is to create a standardized interface for retrieving jobs from job board APIs. Basically, it allows you to get a known response no matter what job board you query. It’s an open source project that I’ve been working on for the past few years (on-and-off), and this iteration is the latest item in a series of improvements I’m making to the whole JobApis (formerly JobBrander) organization on Github.

Read more on JobApis.com.

This is really hard because it’s a subjective and relative title. One thing that I do believe is that the title “senior engineer” has little to do with number of years of experience, but a lot to do with the quality of those years of experience. I ended up coming up with 7 characteristics of senior engineers:

1. They Have Strong Debugging Skills

2. They Know When Not to Do Something

3. They Mentor Others

4. They Review Code Meticulously

5. They Can Communicate Complex Technical Ideas

6. They Specialize

7. They Admit What They Don’t Know

To read more including full explanations of the above list, check out the article on The Muse.

If you have additions to the list, feel free to let me hear them on Twitter.

Isn’t equity in a startup an investment?

When I was just leaving college I figured I wouldn’t have to worry about it. The way I figured it my equity in one of these startups I worked for was bound to pay off someday, so I could just live paycheck-to-paycheck until that happened.

I’ve worked for three early stage startups now, and have a network of friends and mentors who have gone through every stage of growth. One thing has stood out to me from countless conversations: don’t count on equity.

First, even a significant amount of equity in an early stage startup will get diluted. Second, exit events are pretty rare, and without one that stock may never turn into cash. Third, employees get “Common Stock” which means that they won’t get any payout until after investors have made their money back and more. But, this isn’t a blog post about startup equity, so I won’t dig into the topic anymore. Suffice it to say that no; equity in a startup is not a good retirement plan.

So where should startup employees (or founders) start when it comes to retirement planning? Here’s the process I’ve gone through over the past few years, and I hope it’s a helpful starting point for some of you:

Step 1: Spend less than you make, and start saving

That sounds super obvious, but when I talked to one of my friends about it she wasn’t sure if she was spending more than she made.

This is simple to check: just look at your total bank account balance from one year ago and then look at what it is today. Subtract any new debt that you’ve accrued (credit cards, loans, etc.) and that’s where you stand. If the difference is positive, then you’ve spent less in the past year than you’ve made; otherwise, find a way to spend less.

Step 2: Build an emergency fund

Something is better than nothing, so if this whole process intimidates you, start slow. Just open a savings account online and start putting $100 in it every month. Once you get in the habit and you know you’re spending less than you make, build up an emergency fund. This will be a backup plan in case your startup fails, you have a big unexpected expense, or you need cash in a pinch.

Most people recommend saving up 6 to 12 months of your salary in an emergency fund. I’m a bit less conservative, so I keep around 4 months of after-tax salary knowing that if I had to I could stop spending as much on certain things or use my credit cards. It also helps that engineering jobs are plentiful these days so I feel less pressure than some others may.

Step 3: Max out your IRA contributions

Once you start investing real money for retirement you’ll start paying real taxes. If your company has a 401k (many startups don’t, but larger ones may), then put in as much money as they’ll match. Otherwise, put up to the yearly max into an IRA.

I like the Roth IRA option as it lets me pay taxes on my money now and  take it out tax-free when I’m retired, but Traditional IRAs may be better if you think you’ll be in a lower tax bracket when you stop working. Look up the differences here if you’re not sure.

Step 4: Get an HSA if you can

High deductible healthcare plans are the new norm. Whether you’ve got health insurance through your startup or the Affordable Care Act, you may qualify for a Health Savings Account. These are actually really awesome tax-free savings vehicles, especially if you’re young and healthy.

The way it works is that any money you put into an HSA is put in pre-tax. Then, as long as you use the money in that HSA for health care related costs (eg: prescriptions, copays, etc.) then you don’t pay tax on that money when you spend it. If you invest the money you have in an HSA and it grows, it could be a significant amount by the time you retire and likely have bigger medical expenses.

The other benefit to an HSA is that if you do get sick or injured before you retire and your health insurance won’t cover everything, that money can be used without penalty (or taxes) before you’re 65 since you’ll use it on medical expenses. It’s like a medical emergency fund mixed with a retirement fund.

Step 5: Move your money into index funds or hire a fiduciary

IRAs, 401ks, and HSAs are basically wrappers for the money you want to save for retirement.

That means they don’t inherently earn interest, but because most people won’t be touching the money for a long time, they put their IRA, 401k, or HSA money into an investment like stocks or bonds. The reason for this is that compound interest is very powerful.

If you’re completely in over your head at this point, then it might be worth hiring a fiduciary. Don’t just look for the first financial advisor you can find though. Registered fiduciaries are different in that they work for you and don’t get commission from selling you certain investments. Beware financial advisors who aren’t fiduciaries. They’re probably just glorified sales people.

If you feel strong – like you can handle this yourself – then look into index funds. These funds let you buy a large swath of stocks or bonds, giving you instant diversification without the work or buying individual stocks yourself. Read up on diversification of funds too though because the mix you buy when you’re 25 may be very different from the mix you should buy at 45.

There’s much more that could be said on this topic, but since this is getting more advanced, I’ll leave you to do your own research if you’re interested.

Further reading

I read a couple good books on the topic of saving money and investing this year: Money, Master the Game by Tony Robbins (I know, I was skeptical of Tony Robbins too, but it’s legitimately a good book) and Rich Dad Poor Dad by Robert Kiyosaki. A couple blogs I’ve found helpful are NerdWallet and Vanguard’s blog.

Finally, if videos are more your thing, check out How the Economic Machine Works and John Oliver’s spot on retirement plans and the danger of financial advisors.

Have your own tips for startup employees looking to save for retirement? Hit me up on Twitter and I’ll add them here.

Disclaimer: this should be obvious, but I’m not a financial advisor, fiduciary, or even a professional in the industry, so take my advice with a big grain of salt. I’m just an engineer who works at startups and wants to retire someday. Use my advice as a springboard to do your own research or talk to your own financial planner.

When I joined Packback I wasn’t sure what I wanted to do. During my time with the company I went from the team’s only in-house engineer to the manager of a small team. It was amazingly fun, and while I hadn’t been actively seeking another job, when the opportunity to do what we did at Packback again came up at The Graide Network, I knew I would be a great fit.

Here’s a little more information about the company and my role:

What is The Graide Network?

The Graide Network connects middle and high school teachers with qualified teaching assistants to grade and provide feedback on student work.

What that means is that teachers upload their students’ assignments then we find college students who can grade their papers remotely and get them back to the teacher.

My life is full of great teachers who I know first hand are overworked. My mom, a couple of my cousins, my girlfriend’s brother and mother are all teachers, so an opportunity to help make their lives better through technology appeals to me. On the flip side, the college students we get to grade papers are mostly studying to be teachers, so we’re offering them real-world experience as well.

What I’ll be doing

When I joined Packback I had no idea how to fix a messy MVP. I didn’t know how to work with an offshore team, and I definitely didn’t know much about building an in-house engineering team; I had no idea how to create an effective product management process. My time at Packback helped me develop tools and processes for many of the technical problems early stage startups face. At The Graide Network, I’ll be implementing those tools, and helping prepare the company for growth in the future.

Of course, there will be plenty of exciting new features to implement, but the reality is that we’re a company that needs to build a single great feature set before we branch out too far. In the first few weeks I’ll be taking a look at our current web application’s architecture, security, and scalability in order to figure out what we need for a successful fall semester.

Unlike at Packback I won’t have a team yet. We do have a solid local freelance engineer working with us already, so I won’t have to build everything alone. Still, much less of my day-to-day will be management.

In other words, I’ll be doing a bit of planning and a lot of writing code.

What’s next for The Graide Network?

Our imminent goal is to clean up the product for a new round of teachers and Graiders who will start in September. Last year the team (mostly just the founders, Blair Pircon and Liz Nell) worked with a small number of teachers and at times had to grade papers themselves manually. This fall, we’re looking at a healthy pipeline of possibly 10 times as many teachers and Graiders, so a lot of the manual solutions we used before will start to break down. My goal will be to make sure pain points are alleviated by the product.

My next goal is to prepare the codebase for future engineers. It’s very hard to hire good engineers to work on a messy product, and even harder to have multiple developers working on one that doesn’t separate concerns well. If we hit our goals and 2017 is focused on growing the team, then we’ll need to have a good development process and architecture in place.

Finally, I hope to continue to test the systems I helped implement at Packback in a new environment. At Packback I had Jessica Tenuta, a great in-house designer and cofounder, to help with spec and product details. We won’t have dedicated design resources initially at The Graide Network. Implementing a workflow that accounts for this will be an interesting experiment.

I’m sure I’ll have much more to write on the challenges specific to very early stage startups (there are just 4 of us working full-time now), but if you have other questions or comments, feel free to find me on Twitter.

Developing Self-Awareness

In college I made milkshakes at Chick-fil-A, delivered catering orders for a sandwich shop, tested washing machines at GE, pitched at business plan competitions, ran a couple of half-marathons, helped lead an engineering fraternity, and taught myself to make websites. It took me six and a half years to finish my undergraduate degree but, by the time I got out, I had tried enough things so that I knew what I did and didn’t want in my career.

Developing a high level of self-awareness will prevent you from wasting time in a job that you’ll hate, and it makes you a much more effective leader and team member.

Read the rest on Startup Institute’s blog.

Figuring Out Engineering Culture During Interviews

Engineering culture is defined as, “the way we build things around here.” As a job seeker, the difference between working at a company with a strong emphasis on engineering culture and one without is stark.

While you probably won’t be 100% sure what it’s like to work somewhere until you’ve been there for a week or two, there are plenty of great questions you can ask your potential future employers to suss out any red flags.

Read the rest on The Muse.

Dashboards for Agile Teams

We’re big on tracking metrics at Packback, so when I started up a Twitter conversation with Ali Pourshahid, the Head of Engineering at Klipfolio, it made sense to collaborate on an article. This post expands on one I wrote earlier for this blog, and it goes into some of the specific tracking metrics that both Klipfolio’s engineering team and ours at Packback use to help keep tabs on how things are going throughout our sprints.

Read the rest on Klipfolio’s Blog.

This is a random photo I took in Arizona earlier this year. Enjoy!