Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by email or phone:

ayende@ayende.com

+972 52-548-6969

, @ Q j

Posts: 6,707 | Comments: 48,617

filter by tags archive

Full Stack Developer, Master of None

time to read 4 min | 609 words

imageIn 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.

image

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.

If your CV only contains jQuery…

time to read 3 min | 579 words

imageWe 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.

Talking at Sela Developer Practice Conference

time to read 1 min | 116 words

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.

Inside RavenDB 4.0 book is Done, Done

time to read 1 min | 98 words

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.

Inside RavenDB 4.0Book update

time to read 1 min | 66 words

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.

How to really fail a coding interview

time to read 1 min | 154 words

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.

DotNetRocks show on RavenDB with Kamran Ayub

time to read 1 min | 107 words

Kamran Ayub did a great DotNetRocks show about RavenDB 4.0. Kamran is also being the RavenDB 4.0 course on PluralSight, so he knows his stuff.

I got to say, it is… strange to listen to a podcast about RavenDB. I found myself nodding along quite often and the outside perspective is pretty awesome.

Kamran also tested the same application on RavenDB 3.5 and RavenDB 4.0, seeing 20x performance improvement. Best quote from the show as far as I’m concerned:

So fast you aren’t sure it actually worked.

Kamran also have a follow up post with some numbers and more details here.

Listen to the show here.

RavenDB online bootcamp is now updated to 4.0

time to read 1 min | 136 words

imageIn addition to the book and the documentation, we are also working on making it more accessible to get started with RavenDB. The RavenDB Bootcamp is a self directed course meant to give you an easy way to start using RavenDB.

This is a guided tour, walking you through the fundamentals of getting RavneDB up and running, how to put data in and query it, how you can use indexing and MapReduce. These are short lessons, providing practical experience and guidance on how to start using RavenDB.

You can also register to get a lesson a day.

This is now updated to RavenDB 4.0, smoothing the learning curve and making it even simpler to get started.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. Reviewing FASTER (9):
    06 Sep 2018 - Summary
  2. RavenDB 4.1 features (12):
    22 Aug 2018 - MongoDB & CosmosDB Migration Wizards
  3. Reading the NSA’s codebase (7):
    13 Aug 2018 - LemonGraph review–Part VII–Summary
  4. Codex KV (2):
    06 Jun 2018 - Properly generating the file
  5. I WILL have order (3):
    30 May 2018 - How Bleve sorts query results
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats