What does a ScrumMaster do?

Here are three different ways I will try to concisely summarize the ScrumMaster role:

  1. As a ScrumMaster, your job is not to control the team or stakeholders or anybody, for that matter. Your job is to ask questions and make observations that will help lead people to their teachable moment. Whether they choose to learn or not is up to them but you must keep leading them there, every day
  2. Being a ScrumMaster is rather like being a mirror. Every day you are saying “Here is what I am seeing. What do you see?”
  3. Flow is the psychological state when working of being completely immersed in what you are doing. Flow is the most productive (and pleasurable) state in which to perform work. But many Scrum teams start life at the opposite end of the spectrum in a state called thrash. Thrash is that frustrating feeling that it takes 10 units of effort to get one unit of results. It is not a ScrumMaster’s job to manage the team or “make” them perform. Rather, it is his/her job to do everything in their power to move her team towards flow and away from thrash.

What’s missing from the Agile process?

Architecture.

I know. For agile folks, that can be a dirty word. Yet XBOX Live was developed entirely using Scrum with well over 100 developers, in one-week sprints, with continuous integration, without breaking into silos.

And the resulting platform is 100 times more secure than the monolithic PlayStation online platform.

How was it done? Architecture.

Software architecture creates an API that reflects underlying information objects, captures the needs of scalability for different classes of services, and allows the front end to vary completely independently of the back end.

Software architecture allows the partitioning of functionality without losing system cohesiveness and without creating silos in your team structure.

Good architecture is the missing ingredient with most agile teams and without it, you can never be truly agile.

Hire some decent architects.

What are the pros and cons of Sitecore over other content management systems?

Sitecore is a powerful .NET framework and is almost entirely customizable down to its own user interface. It leverages much of what makes .NET great like the role-based security. It allows for a modular templated architecture based on data templates that if done correctly provides a developer with a code-less, do more approach in which content types inherit values and parameters and can be nested to fulfill complex business rules (hierarchical or otherwise) and re-used everywhere. Its API allows for almost complete control of the rendering pipeline, with database-driven content completely divorced from presentation allowing for customizable rendering rules like persona-based personalization, custom device delivery, multi-site (reusable architecture), multi-language and A/B and multivariate testing. Sitecore requires a lot of configuration however both to function as desired and in order to be easy to use. And therein lies the rub, by being so open, so configurable, many developers that cut corners also wreck the content manager’s user experience and make the whole solution difficult to manage, upgrade and deploy.

With its great flexibility for the developer then, comes with great responsibility. You can start with a great platform and get a lousy implementation. Developers who fail to treat the Sitecore platform and their website as an application and apply ALM best practices can easily create an undocumented mess of code and architecture. If programmatic rules are used rigidly without overrides, a content manager can feel hamstrung especially if tiny tweaks involve development and deployment (isn’t that the point of a CMS, to alleviate the need for development). HTML and CSS can be used in-line and hardcoded to particular front-end frameworks to a developer’s peril. However, if you build on a solid foundation Sitecore can act as the integration framework for all your web services, back-end processes, and customer analytics (via the MongoDB platform or xDB, experience database). A developer can build custom e-commerce experience, integrate with CRM, ERP, and manage content for non-sitecore sites, mobile apps and kiosks. If I were a company banking on providing a great user experience for my customers, partners and power users, I’d invest in Sitecore, but I’d also invest in a great technology provider to implement it.

The future of React Native?

The increasing demand for faster app development might be the reason why cross-platform applications are on the rise. In fact, React Native is already perceived as a viable solution to create quality software and its use expected to grow in the coming years. 

Yet, not everyone agrees that it’s the way forward for mobile app development. And rightly so – there are still some technical drawbacks that are holding React Native back, not to mention that it generally offers slower apps when comparing them with native solutions.

Despite the constant advancement of React Native, it does not provide ready-to-use modules that give access to iOS or Android APIs. This forces developers to create so-called Native Modules themselves or develop “bridges” using Java/Kotlin (Android) or Swift/Objective-C (iOS) and severely increases software development time.

Developers bring up one more problem with React Native technology — software debugging. It is much harder when using RN. It comes down to faster development but longer problem-solving which results in less accurate cost estimation (especially in case of Android).

The framework might look strong on paper, but many well-known apps (such as Airbnb or Udacity) has actually switched back to native development. Therefore, even though React Native is definitely a trending topic at the moment, only time will tell if it has the power to outshine native technologies.

How popular are Node.js and Python for web development?

According to this report not long ago, Node.js is used on 0.6% of websites, Python is used by 1.1% of websites:

PHP vs. Python usage statistics, December 2018

With PHP at 78% as the dominate backend language.

Node.js can probably creep up towards 1%, but I’m not really expecting it to.

I think Node.js has probably peaked, maybe if TypeScript gets a lift, it’ll take Node.js with it, but to beat Python, Node.js needs to almost double its market share, and I just don’t see that happening.

0.6% doesn’t sound like a lot, but remember it is 0.6% of all websites.

All things considered, I’d say they are already similarly popular.

What will be the dominant front-end technology in 5 years time?

In short, you might as well play roulette and bet on black, because nobody can answer this question with fact. We can only present hypotheses.

The world of web development, especially front-end development, evolves about as quickly as the physical tech industry does, and there is no way we can predict what Samsung, Apple, Nokia, and the other’s will churn out in even the next two years. Much less five.

Let’s look at a bit of JavaScript history.

Build Tools (2014 – 2018)

  • Three years ago, Grunt was the dominant build tool.
  • Two years ago, Gulp rose up and stole the throne.
  • One year ago, was Webpack’s claim to fame.
  • Somewhere in there, Browserify fought a good fight.
  • At one point, plain npm scripts became a fad.
  • When I wasn’t looking, Rollup rolled out.
  • Along the way, I built Owlister. (It is junk. Don’t look.)
  • Now, Webpack dominates, but tomorrow is unpredictable.

Transpilers (2009 – 2018)

  • Eight years ago, Coffeescript became Earth’s favorite abstraction.
  • Six years ago, Dart arrived like a drunken monkey on weed.
  • Five years ago, TypeScript was born, bringing type safety to JavaScript.
  • Three years ago, Babel arrived to let us use future JavaScript today.
  • Two years ago, Elm became a buzzword. (Nearly irrelevant, but not quite.)
  • Now, TypeScript and Babel rule. Seemingly invincible? Time will tell…

Frameworks (2010 – 2018)

  • Seven years agojQuery was the most suggested JS “framework”.
  • Six years ago, Backbone and Knockout were widely adopted.
  • Five years ago, Angular and Ember took the stage.
  • Four year ago Meteor stormed the gates and built a following.
  • Three years ago, React took its first breath. The prophecy…
  • Two years ago, Polymer and Vue made names for themselves.
  • One year ago, [Angular 2 and Vue 2] released, [bombing and succeeding].
  • Six months agopeople quit caring that “React is not a framework.” Don’t.
  • Now, Angular 4 has arrived, React dominates, and Vue is a super-power.

*These numbers are not exact, but even the absolute correct time-frames would reveal an identical pattern of “king of the hill”. Don’t grill me.

But wait, there’s more!

In the midst of the frameworks timeline, there have also been countless other contenders take a shot at stardom. Aurelia, Riot, Spine, Dojo, Deku, Inferno, Mithrill, Stapes, Svelte, etc. Any one of these lovely ladies could become the new hotness in a matter of weeks. We just can’t tell.

If I were to revisit this answer in five years, I’d most definitely be adding weird framework titles to my timelines above, as even the power-houses of today will not last forever. These tools will probably be such that I have never even heard of at this point in time.

Behold, WebAssembly.

WASM is… difficult to explain. Simply put, WASM allows developers to compile most any language into performant, browser agnostic byte code. What this means is that the front-end community has the opportunity to detonate yet again with a landslide of developers from all walks of life developing for the browser.

JavaScript has done its job well, but as the world progresses it will be replaced. That time could very well be within the next five years. The murderer could be WASM or it could be a new browser that takes a majority of the market share that allows developers to write their applications in Haskel. Improbable, yes. Impossible, no.

The Safe Bet.

As it stands, our best guess is that JavaScript will still dominate the browser in five years. That said, your best bet would be to acquire a slew of developers who are tool/framework agnostic by means of deep JavaScript understanding. Don’t allow yourself to be contracted to a specific tool. I guarantee you that Angular, React, Vue, Backbone, Aurelia… none of these guys will reign in five years.

Those who become proficient with languages and have a firm understanding of design patterns and architecture will have no problem adapting to future tools and are, in essence, future-proof.

Should you learn Docker?

Maybe yes. Maybe no.

If you ever write server/back-end software, it should be a requirement today that you know Docker.

If you create applications, it’s good to know Docker so you can create a standardized build environment. You never really want your application release builds to come off a developer system, and it’s even better if the standard build system can be defined in software.

If you want to run a specific version of a database on your development system, then Docker can do that pretty trivially as well.

If you have problems with version conflicts between various installed environments (Python 2 vs 3, various gcc[lib] versions, other tools installed globally, etc.) then Docker can be useful to set up the perfect environment to run a picky tool, and once it’s working you can share that environment with a coworker and know that it will just work.

Docker is a tool. You should learn it if it will help you do your job. The above examples are not exhaustive. Any time that it would be good to have a standardized environment on your development system, for testing or sharing or running specific software, Docker would be useful.

But if you never need it for the above reasons or otherwise, then no, you don’t need to learn it. It wouldn’t hurt to learn it just in case. But there’s no “should”. It’s really, really not hard to learn, though. At least if you understand the command line.

Why do backend developers have more confidence in their profession than frontend developers?

Because 99% of the time when someone identifies as a front-end developer they are saying that they have not been a developer for very long.

Think of it this way. On the web, Ajax was “invented” in 2004 (actually Outlook was doing it in 1999 but shh…we can’t give Microsoft any credit). It did not become a central part of most web developers’ lives till 2008/2009 or so. Even then, Javascript was avoided by many until frameworks started coming out in the early 2010s.

So what were people who were already established developers pre-2010 doing? Working largely on the back-end. So now that they do a lot of front-end work too, they face the choice, do they brand themselves as a “front-end” or a “full-stack” developer? I certainly choose the latter.

Which leaves most people who embrace the “front-end” moniker as people who have been coding professionally for less than six years. So yeah…they’re less sure of themselves.

For the record, I use the “front-end” and “back-end” terms above in the manner I see them used more often, with “back-end” meaning server-based languages, databases, etc; and “front-end” meaning HTML, CSS, and Javascript. Personally, I dislike those definitions and prefer “back-end developer” to indicate how good someone is at understanding architecture, performance, databases, and security; and “front-end developer” to indicate to what degree someone thinks about human-computer interaction, responsiveness, UI optimization and reusability, browsers, responsiveness, and accessibility. When you formulate definitions this way you start seeing these as two largely orthogonal dimensions of a square, rather than anything mutually exclusive.

Disclaimer: I use 99% rhetorically. It certainly is an overwhelming majority but I haven’t done any data gathering on the subject. That being said, I certainly don’t claim that front-end development is easy. There’s a huge amount of churn. There aren’t many other areas of development where people have to actually stay on top of language specs. 

Why React Dev’s Like to Hate Vue.js

After having worked on React development on medium/large scale apps, I have to admit that VueJS is like a breath of fresh air.

In my opinion, most developers are having as I call it the “Simplicity (Un)reasoning” bias, which means: if it is simple to learn, simple to use then it is for simple projects. Crazy right?

Meanwhile, the arguments in favor of React or Angular 2+ are dubious as well.

Angular is for large teams because it enforces you to write code in a typed way because of TypeScript. Yes but React and Vue support TypeScript or Flow not to mention that Vue’s lifecycle events are more clear cut than React’s.

Vue has only one person writing code. Not anymore.

Vue is for simple projects. Maybe you should read how Adobe is using it these days.

I am not writing this specifically for Vue but believe me that this simplicity can be found in other libraries as well e.g. RiotJS, StimulusJS etc.

Unfortunately, React and Angular have excellent marketing strategies, which plays a major role since they are trying to sell longevity instead of code happiness. By code happiness I mean the factor which make your developers happy to write code they understand and are proud they wrote it. With React and Angular I am not that happy, especially with React.

With Vue the selection was being made from a pool of 10+ team leaders because it just works as it should out of the box. Their vue-cli is also in the same league angular-cli is, but the difference is were angular could not operate very efficiently without, Vue could work without it with no problem.

Finally, I have to point out that lately among the majority Front-End developers, there is this strange notion that if your code is easy to understand, not very complicated and not using the latest ESxxx you are doing something wrong. If you look at Angular you have to learn RxJS, TypeScript etc. and even if you are not satisfied with this selection few will admit it. We have to get rid of the herd mentality and marketing strategy of 2–3 large companies and exercise common sense and independent spirit.

How do you know if you wrote readable and maintainable code?

Dissecting the question, we have two operative terms here: “readable” and “maintainable.”

Let’s talk about what these mean.

“Readable” would describe code that is understood without much inspection or explanation by another developer. You have to choose what parameters you want to describe the “other developer” to know what would be readable to them.

Some things are somewhat universal and limited by human factors. For example, few people can follow poorly named variables. (There’s your first heuristic – are there clear names for variables, classes, methods, and other references?)

Other things are a bit more nuanced. For example, if the developer uses the language you are writing in on a regular basis.

Or, is the developer familiar with the domain the project operates within? How experienced are they as a developer? Do they have a particular background that might make the code more or less readable to them?

But what if you don’t know who the other developer is?

This is why we develop standards, patterns, and best practices. For example, JavaScript code tends to use camelCase, so writing your code with camelCase provides a sense of fluidity (which plays into readability). Knowing the common patterns and style that the language typically uses is important. (As an additional note, your organization may have your own style defined; follow it.)

Some simple, practical heuristics to follow:

  • Use descriptive variable names. Longer variables are more easily read.
  • Use whitespace! Compilers and minifiers mean that whitespace is free. Take advantage of this.
  • Practice finding a balance between abstraction and practicality. You do not need 10 layers of redirection for simple tasks; start with the simplest approach and abstract during a refactoring process.
  • “Make it work, make it right, make it fast.” In that order. This will immensely help the readability of your code, because you start first from comprehension, and then move towards performance. This establishes your pattern and semantics up front, and you are more likely to maintain good semantics this way.
  • Know your audience. If your audience isn’t used to inline lambda calculations, skip it. Even if you believe it is the “best way” to solve the problem, there are other equally good ways most likely available.
  • Follow well-established refactoring and OO patterns. Seriously. These things have been tried and tested, and they work. Look here for a good description of many of these patterns: sourcemaking.com/design_patterns
  • Don’t follow rules blindly. Take some time away from the code and revisit it – what sticks out as weird? What sticks out as confusing? When does your brain feel tired?
  • Readable code isn’t always maintainable, and vice versa. Maintainable code is established by following good practices and principles.
  • Tests are HUGELY important to codebase maintenance. Having good test coverage keeps you from having to load all of the codebases into your working memory (in your head), and reduces errors. (Note: tests won’t eliminate errors altogether; they are there to help you, not to make you obsolete.)

All-in-all, coding is a human process. Follow Hemingway’s advice when writing code. Simpler is typically better.