I’m writing this post as I’m sitting in the airport, leaving the CodeMash conference. This has been my first “true” conference for a while, because I was able to not just speak and stand in a sponsor booth but actually participate in a lot of sessions and talk to a lot of people. I had a blast, and both the IRS and my wife consider this a work trip .

I have been presenting in international conferences for over a decade now and I wanted to put in a few words for people who are speaking at a technical conference. None of this is new, mind. If you have been reading any recommendations about how to present in conferences, I’m probably going to bore you. I’m writing this because I saw several sessions that had technical issues in how they were delivered. That is, the content was great, but the way it was delivered could be improved.

Probably the most important factor that I need to mention is: Make your content readable.

When you are presenting, use big fonts everywhere. That means that (ahead of time) you should make sure that your PPT’s content is readable from the end of the room, if you are presenting code in an IDE, make sure that you know how to increase the zoom so the code is readable. For that matter, syntax highlighting is not an optional feature when showing code.  And use the default syntax highlighting for the language you are working with. And no dark themes.

I’m assuming that what you care about is the code, so you want to show that, in a way that the people in your talk are familiar with, so no new themes, aqua on pink color schemes, etc. Go with the default.

But code is just one factor of it. If you are showing output, make sure that this is readable. That means that if you are writing to the console, make sure that the console font it big enough, use colors for emphasis, etc.

If you are showing XML / JSON / data formats, make sure that they are pretty printed. If you dump something like this:

The audience is going to be too busy parsing the text to actually pay attention to what you are saying.

And if at all possible, use a console application and have no architecture.

If you are actually talking about a React app, you can’t do that, and if your talk is about architecture, you are going to need to show that. But for most cases, if you are showing off some new language feature, or talk about a particular service or API, you want to use a console app to demo it. This is because it allow you (and your audience) to focus solely on the problem at hand rather than look the the control –> service –> repository magic via DI that hides a lot of the backend details.  In general, you want to strip away as much as possible that isn’t directly core to your topic.

Another thing that I noticed, when you want to show additional data (files, artifacts, etc), make sure that you have them already opened before you start.  If you are doing a demo, have screen shots available for when / if the demo mess up.

Everything I just mentioned might seem obvious, but you need to go over that before you go and present, it was surprising to see several speakers make some of these mistakes.

Now, to be fair, that might sound like I’m piling on people, but that isn’t my intention. I’m aggregating a lot of different small mistakes to point them out, they can detract from the presentation, but at least in the sessions that I was at, they didn’t kill the presentation for me.

Next week is CodeMash, in Ohio. I’m going to be at the conference and I have a talk about extreme performance architecture. I’m going to try to condense in 45 minutes the lessons that took us a decade to learn and almost two years to implement. That should be fun, but as much as I enjoy speaking, it is the first time in a while that I’m actually going to go to a conference, not just be there at the booth, and that is really exciting for me.

I took a look at the schedule and there are some interesting workshops and sessions.

Without any particular order, here are the things that popped out as stuff that I would like to be at

BTW, to the CodeMash people, not being able to link directly to the sessions is a PITA.

Workshops:

• Up & Running with Graph Databases - Greg Jordan – I would love to get a feel to how things are looking from the side consuming the graph API, not the one implementing it. If all goes well, I might do a series of posts on the exercises in the workshop as it pertains to RavenDB.
• CodeMash CryptoParty - Dusty Burwell – I have a love/hate relationship with cryptography. I find it fascinating but the math is usually beyond me,  so I can’t understand it (that’s a joke).

Sessions:

• Making and Baking an Application Security Department - Bill Sempf – Following up on the crypto party, this is an are that I care deeply about, so it is worth the 8AM timeslot to learn more about this. I’m also interested in how I can, as an infrastructure, meaningfully contribute to the application overall security.
• 7 Reasons why your microservices should use Event Sourcing & CQRS - Hugh McKee – I’m familiar with both CQRS and microservices, but putting them together seems interesting. I’m mostly wondering about the data flow paths in such a system as the data is required on multiple servers.
• "Did you get my message?" - A comparison of several modern messaging platforms - Jack Bennett – This is very close to what I usually do, and I went over ZeroMQ’s code a few time, so that would be interesting.
• Building a better audit log - Craig Hills – this is a pain point in many cases, what to log and how, and the tension between logging too much and too little.
• Database DevOps with Containers - Rob Richardson – I think that my interest in this one is pretty obvious .
• Bluetooth Prototyping with the Raspberry Pi – I’m using my Raspberry Pis to run clusters of database servers, I wonder if there are other possible uses for a 25$ machine…
• Extreme Performance Architecture - Oren Eini – I’m giving this talk, so I guess I gotta.
• Pivot: How to proceed when things don't work out - Jay Harris – This is in the same timeslot as I’m speaking at, but I would have like to listen to it. Failure, planning for failure and recovering from it are all very important skills.
• ZAPping Security Vulnerabilities in Your Development Pipeline - Matthew Smith – This seems like it would be a session that cover an eminently useful skill.
• My users posted what? - Harold Pulcher – I don’t have a direct use for the topics discussed here, but it seems interesting, and I like learning for leaning sake. At some future time, it always pays off.
• APIs on the Scale of Decades - Gary Fleming - RavenDB is ten years old, and I’m certainly feeling the pressure there.
• THE STORIES OF THE MOST INFAMOUS BUGS - Ian Zelikman – Because who doesn’t want to see a clown slip on a banana peel, and this is the high tech equivalent.
• Data management in a Microservices world - Gerald Venzl – This is a topic that I have been thinking a lot about, and more information there would be very useful.
• Patterns and Architectures Beyond Microservices - Stephen Shary – should be interesting, some of the patterns that are mentioned in the description aren’t known to me and I have to exert some willpower not to search for them and wait for the session.
• Post Mortem: Dealing with Failure in Development - BJ Burns – Already said that this is an important topic, so this session is also very intereseting.
• Building A Highly Scalable Service that Survived A Super Bowl - Keith Elder – Because if nothing else, the story is likely going to be awesome.
• Comments are Useless and Other Controversial Opinions About Code - Izzi Bikun – This sounds like a fun session.

There are a lot of other stuff there that looks good, and I don’t even know if I’ll be able to get through all these sessions (not actually possible, there are timing conflicts between some of them). But the point of the conference isn’t just to sit in the sessions but the hallway interactions and actually talking with people.

I’m looking forward to that and I’m bringing a few books and some swag as well, if anyone is there and is interested.

I’m really looking forward to it.

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.