I’ve written about the technical interview before. I’ve written both for and against code interviews. And I’ve provided both C# and JavaScript questions to weed out fake programmers. But a little more experience under my belt has me rethinking what makes a good interview.

Now, you may wonder why I think I’m particularly qualified to speak about the interview process. Most people who have opinions about the interview process in particular have it from only one side. The one of being the guy looking for a job. And, most of you only interview when you need a job.

What makes me qualified is that, I help interview people looking for a job and I interview for lots of jobs. In my opinion, you should be interviewing for a job, even if you don’t need one, at least twice a year. I interview more frequently than that. In the last 6 months, I think I’ve interviewed at least 4 times.

So, let me start by telling you what the current interview process looks like, and why it doesn’t work. Then, I’ll move on to the few interviews that I believe captured the information everyone was looking for quickly and how you can move the conversation in this direction regardless of what side of the table you are sitting on.

Read More

I was asked this past week what my thoughts were on Angular 2. I wrote early on about my impressions of Angular 2 when it was barely done enough to review. But now that I’ve been working with it for a while and know a bit more, what I want to discuss is more along the line of what it means to the average developer and, more importantly, organizations that are planning to use it.

Options

While like Angular 1, Angular 2 provides us with most of what we need to build an application. Angular 2 also provides us, out of the box, with very Angular 1 ish ways of putting together an application, complete with modules. What Angular 2 provides that isn’t quite so obvious going into your development is options.

In angular 1, we had options at the GUI level. And while this is still true for Angular 2, this is not the only place where you will see options.

In general, you can split your options into, 1) do you want to do things the Angular 1 way, or 2) would you like to use an approach that looks more like React.JS? No place is this more obvious than with how you deal with forms. You can create forms with a declarative syntax, like you’ve done with Angular 1, using Template Syntax. But, in my opinion, a much better way to create forms is with a more reactive approach using the FormControls and FormGroups classes. If all you are doing is just displaying data, you’ll probably find that using the template syntax is all you need. But once you start working with complex forms that accepts data input and implements validation, you’ll probably want to move toward a more reactive approach. The added benefit is that more of you code will be testable.

The next option you are going to have is figuring out how to move data around your system. Most of the literature is going to suggest you use a data flow that looks a lot like what you were doing in Angular 1. But there is nothing stopping you from using Flux, Redux, or even RxJS instead. And here again, my recommendation would be that you learn these because I think you’ll find that your system will end up being much easier to reason about than the old MVVM stuff you may be used to.

Lazy Loading

There are several places where we had to make choices in Angular 2 where the feature has been built into the framework. One of these places is lazy loading. Why load all of your JavaScript up front? Load what you need when you need it. Angular 2 makes this easy with Lazy Loading and the choice between using WebPack (the default) or System.JS.

I’ll warn you though, as of this writing, Lazy Loading only really works when using System.JS unless you want to spend a lot of time tweaking your webpack config file.

Angular 2 CLI

Command Line Interfaces seem to be the cool new kid on the block. You aren’t a real framework unless you have one. While the Angular CLI is not quite baked yet, I can see how this is going to make writing Angular 2 apps much easier. There are a lot of moving parts involved in getting even the most basic of applications up and running. The Angular CLI makes starting your first application REALLY easy. It even hides all of the WebPack internals while allowing you to add your own config file if you need to. Once they have the routing bit re-implemented, it should make using Lazy Loading with WebPack much easier.

The other thing using the CLI will do for you is that you will automatically start following the coding standards that the Angular team have developed.

Angular 2 Components

Right now, there aren’t a lot of options available for Angular 2 for custom components. While Kendo UI has been the defacto standard for Angular components in the past, Telerik is in the middle of rewriting Kendo UI for Angular 2 (and React.JS). I haven’t seen any movement in the Angular UI camp to support Angular 2. Angular 2 Material has a few components that seem ready, but they are all relatively simple. The only vendors that seems to have a complete Angular 2 package is Wijmo and Prime Faces. I haven’t tried them and I’m not endorsing them. I’m just reporting what I’ve found. There are a few standalone components here and there, but if you are looking for a set of components you can just use from one source, I’m afraid you’ll have to wait. This isn’t necessarily a bad thing. It gives you time to properly learn Angular 2.

But what about the Angular 1 to Angular 2 bridge? In my mind this is way more trouble than it is worth. We’ve waited two years for Angular 2, I think we can wait just a bit longer for a set of components that we can use with it.

What Angular 2 Means for You

The main difference between Angular 1 and Angular 2 is that just about any Script Kiddie could pick up Angular 1 and get something done. Angular 1 was developed during a period of JavaScript history when JavaScript had not quite reach the level of “serious programming language.” But now, JavaScript has not just reached that level, but several very serious frameworks have been developed.

What I notice as I review the JavaScript landscape is that we’ve moved from just getting stuff done with little to no planning, to treating JavaScript as a first class programming language that requires, and even demands that we adhere to a set of programming best practices that we would use for any other language. These include things like naming conventions and design patterns. For you to write code well in this new universe, you will need to understand what these design patterns are, why they exist and how to implement them well. If you continue on your merry script kiddie way, you will soon find yourself out of work.

Further, if you think you know Angular 2 just because you know Angular 1, or you think Angular 2 will be easy to pick up because you know Angular 1, you are in for a very big surprise. Many of the concepts are the same. But since Angular 2 has so many options, you should learn the options well so that you can make an educated decision about which option to use.

What Angular 2 Means for Organizations

Similarly, if you are an organization that is planning to move to Angular 2, don’t expect your programmers to just pick up and move to Angular 2 overnight. Give them time to learn it. My recommendation is that you make learning it part of their job while they continue to use Angular 1 for the product you are trying to complete. We all have time pressure, so you need to factor learning into the schedule.

But Angular 2 may also mean you need to find additional programmers who already have the skills and can transfer the knowledge to your team.

This past week I got into a small discussion about the importance of loosely coupled code.  Specifically, I was looking at event handler code that did nothing more than change the size of another element on the screen.  But the event handler code was in the controller which in the particular implementation we are using was the event handler portion of our Model in a MVVM architecture.  The question becomes does this code belong in the view, or does it belong in the controller? The question of where code belongs leads eventually to arguments for loosely coupled code.  If I put code in my controller that is manipulating the view, then I either need to mock out my view in order to test my controller or I have to have an instance of my view available to test my controller.  Having coded enough systems to know that both of those choices are problematic, I opt for placing the view specific code in the view.  Another place where you might place this code would be in a View Specific event handler class.  But that would only be for the purposes of clean separation.  Something we might consider doing if the View were plain HTML.  But in our particular case, the view is generated from code, so placing the handlers in that same code seems to be the most appropriate location for it.

But all of this leads to a larger question.  Why should your code be loosely coupled at all?

Read More

There have been a number of things that have occurred over the last week that have prompted this particular post.  And for anyone I work with, this is not an indictment of our work place so much as it is an indictment of our industry.  PLEASE don’t take this personally.

Some of those reasons will show up in this article.  But the question we need to examine today is why is it so hard to write bug free code.  And I’m not even talking about perfection.  Why is it that we miss the simple stuff?  The stuff that once it is found, we think, “how could we have missed that?!”.  I’m perfectly aware that all code has bugs some just haven’t been found yet.  I’m also aware that no matter how hard I try, the stupid bugs always make their way past my desk.

Read More

Have you ever noticed how, when QA reports a “defect” developers tend to bristle?  I first noticed this in myself a few years ago.  Now that I’m functioning as a Scrum coach, I’m noticing it in others.

Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial?  I think so.

I believe there are some adjustments that need to be made organizationally and personally that will bring these two groups together.

But first, why does this problem exist in the first place?

Read More

We’ve all been there.  Either at the micro level or at the macro level.  Business wants to know, “How much is this going to cost me?”  And as software developers, we all know the answer is, “more than you were expecting.”  We also know that whatever number we give will probably be wrong for a number of reasons.  Chief among them is that no one really knows what they want until they see it.

And yet, there has to be some way of providing business what they need and still allowing for unknowns.

So what follows are a few tips on estimating that help you estimate software projects like a pro.

Read More

Over the last week, I’ve been helping other programmers estimate the task they’ve been assigned and this has caused me to reflect on how I estimate software.  What works.  What doesn’t.  What mistakes I see people make.

There has also been a move to avoid estimates entirely.  The argument goes something along the lines of, “we know the least about a project at the beginning of the project, so we can’t really give an accurate estimate.”  Which is mostly true.  And yet, there are people who need to know “how much is this going to cost?”  What do we do for them?  How do we balance the two realities? And then all of this lead me to think of all the ways we sabotage our estimates, or our estimates are sabotaged for us.

You might think that estimating projects only applies to project managers.  But the truth is, most places I have worked rely on programmers to give them estimates, and frankly, most of us screw this up.

Read More

I’ve written about using Selenium to test web applications before.  But all of those articles have assumed you are using C#.  I’ve realized that Selenium has multiple language bindings which allow me to use any language I want but C# just seemed easier at the time.  But, now I’m in an environment that doesn’t use .NET at all.  They use Java.  I know Java, but I choose not to use it and instead my focus at this shop is all JavaScript.  Which means, if I want to write Selenium tests to verify my work, I need to write my tests in JavaScript.  But Using JavaScript to Drive Selenium is, in my opinion what everyone should be doing.  At least everyone who is writing most of their web application using client side code.

Read More

We’ll get to Reasons Projects Succeed soon, but I need to do some setup work first.

I’ve been thinking about starting an Open Source project for a while.  The only issue was; I didn’t have an idea for a project that didn’t already exist.  Now I do.  So, I’ve begun the process.

The issue with starting a project like this is that I would much rather just start coding.  In fact, I would much rather not even make this Open Source.  But making it Open Source has forced me to face project management issues head on.

I’ve been listening to enough podcast recently to know that putting something up on GitHub isn’t going to make a project Open Source any more than it will make it successful.  Therefor, I’ve decided to start the project as though it had a team of people already working on it.  It is a team of one for now.  But, one thing I’ve learned in life is that having the structure in place to handle a larger team now will not just benefit me in the future, but it will actually help my small little team of me today.

I’ve started looking at other successful Open Source projects to see what they are doing and to determine what components of what they are doing I want to include in my project.  As I’ve gone through this exercise, the thought occurred to me, “If the organizations I’ve worked for implemented half of what these projects implement, the projects would have been run so much more efficiently and the projects that were in trouble may have avoided the trouble.”

Read More

I was just getting started writing an article about using Node/JavaScript to drive my Selenium tests and as I was writing the “Prerequisite” section, I realized I have never written the basics about how to get setup with Node or even why you would want to.

As popular as Node is, I am still finding that many of the people I work with have no idea what it is or if they do, they only have a partial idea and can’t see how it would apply to the work they do on a daily basis.

So, let’s start with the fundamentals.

Read More