I’m going to be traveling extensively in the first part of 2019.

On January, I’m going to be in Sandusky, Ohio for CodeMash where I’ll be speaking about Extreme Performance Architecture, how we were able to refactor RavenDB to get insane level of performance. I’m going to be covering both low level details (there might be some assembly code) and the high level architecture that make it all possible.

On February, I’ll be in the RavenDB booth in the O’Reilly Software Architecture in New York. You should come and see what goodies we’ll have to show off at that stage. If you are in healthcare, we’ll also be at the HIMMS conference in Orlando where we’ll showing off some of the ways RavenDB make working on healthcare software easier.

I’m also going to have an event in New York in February (details to follow) in which I’ll speak about a grown up database. How RavenDB is able to run without a dedicated admin and what kind of behaviors you can expect from it.

On March, I’m going to be visiting the Gartner Data & Analytics conference in Orlando, you can ping me if you want to sit and have lunch there.

On Oct 18, Rodrigo is going to talk about how a quick service restaurant chain has moved 36,000 locations (and millions of instances) from RavenDB 2.5 to 4.1.

In this session you will learn:

• Why RDI Software chose RavenDB for its quick service restaurant platform?
• All the hurdles that massive-scale deployments add to the mix
• How the migration to Version 4.0 enables the future vision of our platform?
• What were the trade-offs we had to make in moving from one version to the next?

Please register for the webinar in advance.

In my previous post, I was asked:

Is it reasonable to look for a developer who knows all the complexities of backend development (Particularly for the enterprise, at least while designing distributed applications or Micro-Services) and expect them to know React, Angular, TypeScript, and many other front-end technologies on the same level?

In my experience, it is absolutely possible to have someone who is fluent in both front end (React, Angular, etc) technologies and backend technologies (databases, k8s, distributed systems, design patterns, etc). I can point at two or three of them without searching too hard. The problem, however, is that while it is possible, it is also rare. The people I have in mind who qualify for the full stack developer moniker are also people with about a decade plus of experience in the field.  And make no mistakes, I don’t include myself in that category. I can use a user interface, but don’t ask me to build one.

For the most part, I see people who exists on a spectrum, and are typically strong in certain areas and have passing familiarity in others. For example, you may have someone who is very strong in building client side user interface and calling back to the server, with some ability to create their own server side endpoints, but without the capabilities to build a full server side solution from end to end. On the other hand, someone who is capable of building the server side, maybe do some client side work, but is stumped on the more complex issues on the client.

Now, I’m speaking in generalizations here, because I’m talking about large segments of developers, not individuals. But this seems to hold true for large swaths of them. It also make sense, there is quite a bit to learn, and you can either be a butterfly and skim through a lot of subjects, or you can dive deeper and become an expert on a few topics.

Either option has its value, but it is important to remember that each also has its costs. If you have dipped your toes into many areas, you don’t usually have the depth to actually handle the more complex and non trivial stuff. For example, I would generally not expect someone who spent most of their time on the client side to be aware of everything that needs to happen for a proper server side caching solution.

When talking about skills in an area, I’m talking about being able to develop, support, debug and maintain such a solution. Everyone can write code in most areas, but it takes effort, skill and knowledge to take a piece of code and turn that into production software.

The term full stack developer is a way to punt. It usually says “I do a little bit here, and little bit there”. There is some meaning here, in the sense that these are the people you’ll turn to when you want to build a full application from scratch. The problem is that they are usually only able to deliver an application that does OK across the board. When you need to do more than OK (and I’m willing to admit that in many cases you don’t), you start to need to specialize. And that takes time, and effort. I would rather the term application developer, rather than full stack. If seems to be more accurate and it doesn’t ping my spider sense about false advertising.

We recently got a CV at the office, from a developer that has about three years of experience as a Full Stack Developer. The CV was… strange, in the sense that I was intimately familiar with all the web technologies in it. This is peculiar, because about five years ago I just threw the gauntlet and stopped even trying to pretend that I have any skills in building anything that is near the front end. And my skills as a front end developers has been atrophying even before that.

I mean, <table> is still how you properly layout things today, as far as I’m concerned. However, in a rare moment of self reflection, I have to admit that I wouldn’t hire myself to do anything related to the browser.

So we have a CV with the following keywords:

• HTML
• CSS
• JavaScript
• Ajax
• jQuery

And that’s a bit suspicious. Oh, certainly these are foundational topics for a front end developer, and I get the need to sometimes pack a CV with keywords for the purpose of matching. However, not having anything else there is strange, and not usually indicative of a good outcome. We gave the candidate a call and talked for a bit, nonetheless. 

It appears that the first job the candidate had after university was maintaining and building an already existing application. The architecture and framework choices were already done and there hasn’t been any pressing need to change them. Therefor, that was what the candidate was used to and familiar with.

So far, this is reasonable story. I can certainly see how this can happen. What I don’t understand is the candidate’s reaction to that.  Sure, the current job may be resistant to changing things. It works, probably reasonable well as far as the current workplace is concerned. And moving to a new technology just because a person want to (literally in this case) pad their resume is a bad idea.

But what about the candidate? At this point, they are actively hunting for a new job. I would expect them to take a look at the market, evaluate their current situation and identify that they are currently working on something that give them no real value for prospective employers. In fact, I would be willing to bet that this is a large part of why this candidate is looking for a new job.

I would expect the candidate at this point to actively work at improving their skills. Spend some time watching Plural Sight videos, build sample applications, go over tutorials, etc. Coming to a job interview and saying something like: “My current job only uses jQuery, but I have been studying React on the side using Plural Sight and here is my GitHub’s sample project showing my progress so far” is amazing. It indicates a lot about the candidate, including the ability to learn and develop oneself on your own.

We aren’t going to go forward with this candidate, but I’m certain that they will be able to find another position in a company where their jQuery skills will be very valuable. However, I don’t expect that they’ll learn anything new in that place, and in 3 years or so, if they will be looking for a new job, they will be in the same exact same place.

On an unrelated note, I have another CV which listed both WinForms and VB6 as core skills.

Here are the slides from today’s talk.

I’ll be speaking tomorrow at the Sela Developer Practice Conference. I’m going to talk about:

• Staying Friendly with the GC
  
  .Net Garbage Collector is an important factor in improving development efficiency by eliminating the need to manually manage memory.
  But sometimes, it's overhead may cause very long pauses in application execution. In this talk, I will show why this happens and how we can deal with it.
  
  
• Rebooting Design
  
  

This talk will explore how we REBOOTED our Project Design. After a decade of production usage, the RavenDB team addressed a lot of ongoing concerns & changed some of RavenDB's core architecture.
We'll investigate the driving forces behind it, the reasoning process & look at how it all turned out.

The Node.JS client for RavenDB 4.0 is out. You can get it directly from NPM. Here is how this looks like:

Enjoy .

And now the book is another tiny big step close to actually being completed. All editing has been completed, and we did a full pass through the book. All content is written and there isn’t much to do at all.

We are now sending this for production work, and once that is done, I can announce this project complete. Of course, by that time, I’ll have to start writing about the new features in RavenDB 4.1, but that is a story for another day.

You can get the updated bits here, as usual, I would really appreciate any feedback.

Just to let you know, the book is pretty much edited, that means that you won’t have to suffer through my horrible sentence structure.

You can read this here.

What remains to be done now is for me to go over the book again, verify that there aren’t any issues, and we are done.

In other words, we are now “Done, Done” in the “Done, Done, Done” scale.

Our current interview question is from this post. We use that between the phone interview and the actual interview to get a feel about a candidate abilities. You can learn a surprising amount of information from even small amount of code.

Note that one of the primary goals of such a question isn’t to tell you “You should really hire this candidate” but to tell you that “You really shouldn’t”.  To clarify, this is a “do it on your own, and you got the whole internet at your disposal” kind of question. Typically we give a week or so to answer this.

Sometimes we get a very clear signal from the code, like in the case of this code:

But I think the crowning glory was this code:

I picked two of the worst offenders, but there were more. Some things I can sort of let slide, and some things I’ll just say no to.