I have spent a lot of time trying to figure out what ‘Agile’ is. Back in the early/mid 2000s, after the tech bubble and before the great recession of 2008, there was a brief period of optimism and solidarity in software engineering. We learned a lot from the booming late 90s and from the bubble bursting in 2001. Aside from the economic turmoil there was also turmoil in the personal lives of engineers and developers.  120 hour work weeks, sleeping in the office, breakups, divorces. It was a lot like the gold rush out west in the 1800s, but instead of a material commodity it was information and access/sharing of that information that began really generating revenue and movement.  Along with individuals going gangbusters to get a piece of the information/technology pie, large companies became more excited or greedy about getting a piece of the pie or even a bigger piece of the pie. This lead to many companies rushing plans together that were not the most well thought out and squeezing every drop of production out of their employees.  California, being one of the first to go through a cycle like this, implemented their overtime law. This basically says that even if an employee is on salary, if they work over 40 hours they’re entitled to 1.5 X their pay per hour.  This was implemented because companies were hiring their employees and paying them a ‘good’ salary but then pushing them to work 3X as many hours and thus resulting in a pay cut in reality.

We Respond And Change

After living through and seeing all this happen through the 60s, 70s, 80s and then the 90s, a group of experience people got together and started….’Agile‘!  This is Agile…right here…on the next line…that’s it…read it and pay attention!

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

You may have read that and thought ‘where does that mention sprints?’, or ‘they didn’t mention the burn down chart!’…etc…etc.  That’s because those things have nothing to do with Agile at all.

I often hear people compare Agile with the Waterfall Model and that really doesn’t make a lot of sense. Agile is a philosophy and the Waterfall Model is a development cycle model. While in college, in my last year, I chatted with a professor about this difference and why I thought it was significant because there was a final version of the Waterfall Model that I thought would work pretty well.  In theory Royce’s Waterfall Model  could even be executed in an Agile environment. The Agile Manifesto is a set of values to be applied when working with humans and in realizing this I think those values are far more powerful than any development cycle or methodology that will ever exist.

We Practice

Try making the Agile Manifesto the first thing you read in the morning before you start working for 1 week.

Individuals and interactions over processes and tools

The next time you hear someone complaining about a process or tool ask them how they would fix it or update the tool.

Working software over comprehensive documentation

When people ask for documentation, make sure that there’s something out there to document.

Customer collaboration over contract negotiation

Work with your client/customer/boss/coworker to figure out what it really is we’re trying to accomplish instead of blindly doing something and then falling back on your contract/agreement when your product misses the mark.  Building better software/products means we have to own a project if we’re participating in it.

Responding to change over following a plan

If something isn’t working…stop…turn…go. None of us live long enough to waste time follow a plan we’ve proven doesn’t work.


Remembering that Agile is actually a set of values and not a methodology could really open up our eyes to improving our methodologies over time. We have been clinging to ‘Agile Methodologies’ too tightly and with that we have ignored one of the Agile principles, “Responding to change over following a plan”.  Let’s keep responding to change and valuing people and interactions over processes and tools to move forward in creating better software for people that can bring us to a better future as humans.


Um, it’s not that long…just go back and read it 🙂


What are Senior Developer/Engineer Skill sets?

Previously we discussed the skill sets the “Web Developer” title.  Logically the next step would be “Senior Web Developer”.

Disclaimer: What I’m about to go into may not reflect your skill sets or knowledge  even if you have a “Senior Web Developer” title and conversely, you may possess all of these skills and have a “Web Developer” title. The reason I’m writing about this is because I’m aware of inconsistencies in the industry and I think we should all work to get on the same page. I’m not advocating that people get promoted or demoted based on these definitions. There are other factors that go into getting promoted which aren’t based specifically on skill sets.

senior |ˈsēnyər|


1 of a more advanced age: he is 20 years senior to Leonard.

US of or for students in the final year of college or high school.

• relating to or denoting competitors of above a certain age or of the highest status in a particular sport.

Being “Senior” is not exempt from relativity but I do think there are a few fundamental elements that make adding “Senior” to someone’s title a good idea.


There are probably many other terms for this, but here’s what I mean.  As a Senior Web Developer you should be aware that you work on a team. Sounds more simple than it really is. You should be aware that learning how to work with your team takes time and a lot of attention. Everyone is different, everyone comes from different backgrounds and responds differently to all forms of communication. I think anyone with ‘Senior’ or ‘Manager’ in their title needs to pay close attention to the people they work with and remember the most effective ways to communicate with each one.

Acknowledging that everyone is human and has strings of good days and strings of bad days, so you have to be patient. Each person has a context.

That said, you should also be able to distinguish between an employee having a bad few days and a bad employee. Leadership needs help identifying these people and accurately evaluating them and that is something a ‘Senior XYZ’ should be able to do.


Not only knowing the difference between doing something the right way and the less right way, but also when to do it the right way and when to do it the less right way.  There are trade offs in development all the time. As much as we would like to do everything the “right way” all the time, it isn’t always possible when working with a team to get something launched.


Experienced people should be humble. They know where they came from and what it took to get to where they are now. They will have been wrong more times than one can count. They should be the first to admit it once they notice they’re wrong and also accept responsibility. Being wrong happens all the time, it’s how people learn in cutting edge fields, we’re pioneers a lot of the time and you’re bound to make mistakes when few people have traveled down the same path.


So I think this is important but not as important as the things above.  As a ‘Senior Web Developer’ you should know what’s currently going on in web development. That sounds like a given, but I’ve interviewed a lot of people that have enough time in the industry to be ‘Senior Web Developers’ but couldn’t answer simple questions about what’s current in the field. You should also be able to take a good guess at what’s a passing fad and solid technology that’s here to stay. This is very important when you’re picking technologies for new or current projects.

I would also assume that you have some deeper knowledge in how web technology works and what the web is built on. Networking, DNS, Sessions, Deployment strategies, testing are just a few areas I would expect a ‘Senior Web Developer’ to be comfortable talking about.


Looking at senior job listings, the big difference I see in them versus non-senior is the amount of desired experience at the bottom. Non-senior positions usually ask for 1-2 years of experience and senior positions ask for 5+ years of experience. I think this is simply because they don’t know what they should be looking for. Having Senior in our title implies more than just knowing some technology and having worked in the industry for more than 5 years. It’s about people and adding value to the company not just through your self but through your team as well.

What are Senior Developer/Engineer Skill sets?

What are Developer/Engineer skill sets?

This is the beginning of a multipart series of posts. While I know this won’t be perfect and people will probably have disagreements, I actually hope we can talk about it a little bit and maybe come to some standardization and unification.

Job definitions are hard, because in most cases working in the technology field, you will end up doing a lot of different things.

Today I want to investigate the title of “Web Developer“.

We have all probably heard of this title before and at first glance most will know what the person that holds that title does on a day to day basis. Or do we…

Let’s start out with what we probably agree on.

A “Web Developer” should be familiar with the core building blocks of websites and the best practices of implementing them.

  • HTML
  • CSS
  • Javascript

Keep in mind that there are many tools and ‘technologies’ built on these core languages and platforms. Things like jQuery, AngularJS, LESS, SASS, Bootstrap and so many more.


HTML’s responsibility is to define content and structure it in an organized way. You’ll here the term ‘semantic’ used with HTML/markup a lot.

‘semantic’ means “the study of meaning”.

Semantic HTML is subjective in some cases but there is a lot of content written in HTML everyday and there are many best practices for semantic markup.

Tim Berners Lee, and Paul Irish are big influences that come to mind.


CSS’s stands for “Cascading Style Sheets”. “Cascading” refers to the rules of how styling is applied to HTML and is really the power behind CSS. There are many thoughts behind CSS and how it should be applied and organized. So much so that there are transpilers that enforce or provide simpler access to more complex CSS features.

SASS is my personal preference right now. With CSS it’s important to know about the box model and default browser values for padding and margin to be able to create a consistent experience across multiple platforms. CSS is also where a lot of the “Responsive Design” decisions and management happen.

Eric Meyer is a huge influence on CSS and has contributed a lot of great best practices and design patterns.


Javasript is the core of dynamic websites. Javascript is used for everything from countdown timers to handling complex data manipulation, games and analytics.  Javascript is downloaded by the browser just like images or any other content on your website. Then the browser runs that code inside its own environment.

Javascript is very powerful and also very complex. There are many libraries out there and many thoughts on best practices with javascript. It’s hard to find the right answer for the best way to do something, but a good way to tell is if the javascript is easy to read and understand what it’s doing then it’s probably a good sign.

Douglas Crockford and Addy Osmani have been really influential in the Javascript community.


Next Time…

I plan on this being at least a 1 of 4 part blog post. Next I’ll be covering the “Senior Web Developer” title, followed by “Software Engineer” and “Senior Software Engineer”.

Please feel free to discus and let me know what you think a “Web Developer” does! 🙂

What are Developer/Engineer skill sets?