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.

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.

Return of the Senior Engineer

To paraphrase Mark Zuckerberg, there is a widespread feeling that young people are smarter and senior developers are not needed. But, when you look inside most businesses, you see businesses that are being held back by a lack of senior developers.

What did the founder of one of the largest tech companies mean by this?

Many new startups typically take a year to produce something that is ugly, full of bugs, inflexible, poorly written and practically (but not absolutely) unusable. Then, in year 2, they re-write the entire product which is 10x better yet is plain, still full of bugs, still inflexible, poorly written in a different way and somewhat usable. Finally, in year 3, they re-write the entire product for the third time and, before it is delivered, the investors give up, the startup runs out of money and the startup folds.

This is one reason (but not the only reason!) that startup failure is so high. The startup built the wrong thing in the wrong way and paid the price in years of development time and millions of dollars of venture capital.

Differently, in the biggest tech corporations, the product just slows down and creeps along. After years, the product is reasonably attractive, has a “big” codebase and is not very flexible. New features are small and mundane, and, in the worst cases, simply visual (“a new coat of paint on an old car”). Developers add to the mass of code but simply don’t have the technical ability to see into the codebase and make the changes necessary to make big, new features possible.

First, is it reasonable to expect one senior developer unwind 2 years of design and code chaos, bring to heel a 10-person team of non-senior developers who continue to produce code and whip the product into shape in 6 months? Is it reasonable to hire Michael Jordan to lead your team of rookies in the mid-season and expect him, by himself, to win the NBA championship for you? Yet that’s what a lot of companies expect: that they can hire ONE person to supercharge an entire team or even turn nothing into something amazing.

At a startup, it’s possible that the right senior developer(s) could get the startup to year 2.5 in 1 year. Instead of having your developers finally producing a sell-able product just when it’s too late to matter, you can save a lot of time and some money.

At a big company, the right senior developer(s) can clean up your code base, make it possible to produce big, new features and actually produce big, new features. The focus should be placed on hiring those software engineers who have “experience” dealing with the software problem(s) you have and less about tossing warm bodies at the problem.

How do Project Managers break down requirements into Stories?

A good product manager doesn’t “break down” requirements into user stories, they start with good user stories and work from there.

The whole point of using user stories is that they are how you communicate “requirements” to your development teams — by stating the user persona that you’re targeting, the task that user is trying to perform, and the goal that the user expects to achieve.

If you’ve already got a list of “requirements” then you’re not really using user stories for the purposes for which they were intended.

That said, you may start with a very large user story, such as “A new customer wants to set up an account so that they can access the product.” That story is way too big for a team to do in an iteration, if at all. We generally call these “epics” which can be broken down into “themes” and then further broken down into “stories” until we get to something that a single development team can fully complete in a single iteration. For this story, that might look something like this:

  • Epic: “A new customer wants to set up an account so that they can access the product.”
  • Theme: “A new customer wants to confirm their email address so that they know we have the correct account information for them.”
  • Story: “A new customer wants to enter an email address so that we can contact them if we have information that is important to them.”

Communicating Agile “requirements” using user stories requires a completely different perspective and starting point than traditional product management approaches.

Why do programmers wear headphones while working?

There is one critically important reason to wear headphones while programming. When you understand the impact of this, it will change how you think about what it means to make things and what that process really requires.

Programmers wear headphones so that they won’t be bothered. That much is pretty obvious. The reason why being bothered is an issue is something I’ll get to in a moment.

You see, the modern workplace is designed to ruin programmer productivity. If I were to design an office space to maximize programmer output, it would look like the opposite of nearly every modern office space I’ve ever worked out of.

Actually, I now work in an office that basically maximizes my potential output as a programmer and it really does look like the opposite of most modern corporate offices.

The big gimmick right now in office space design is “open office spaces”. This is designed to improve collaboration (as if that is the great problem of modern work).

Open office spaces really exist so that it looks like everybody is busy working. It looks cool to see so many people busily walking around, talking, and in general looking busy. There is a sound component to it as well.

Open office spaces are loud!

But again, it looks and feels like an improvement over the previous decades’ bad idea – cubicle farms.

Also, open office spaces are cheaper than cube farms, so companies are saving money while making everybody look busy (even at the cost of huge productivity decreases).

In general, all of this is terrible for the actual act of programming.

The art of programming tends to rely on the same thing most art relies on – flow.

Getting into the “flow state” where you are focused on a problem deep enough to make connections and leaps and do your best work without “thinking” is where the real magic of programming happens. This is very similar to playing music, writing, and painting.

Imagine if Leonardo da Vinci was expected to paint the Mona Lisa in an open office space while his coworkers and manager would stop him mid stroke every 15 minutes to ask a question. Would he have ever painted it?

No, I don’t think so.

And yet, programming is a creative process that requires a similarly creative environment as most other art does.

Take authors as a similar example. Stephen King doesn’t “collaborate” to write his books. He sits down at the typewriter or keyboard and starts writing. Imagine if he had to do a daily standup about his latest few pages each day with a committee of his peers.

His work would suffer.

It turns out that to code well we rely on that same kind of process of getting into the flow and doing creative work with our minds. It’s how our brains seem to be wired for creative work.

People like Paul Graham have written about Makers Schedule vs. Managers Schedule before with a similar understanding.

It takes something like 5–30 minutes to get into a flow state. If uninterrupted, time distortion kicks in and a couple hours fly by and a bunch of code is created.

Every interruption resets the clock on that process.

So, what programmers need to maximize flow (and thus output) is blocks of 2–4 hours without interruption. Ideally, a whole day without interruption would allow for as many as 3 or 4 blocks of “flow”.

As near as I can tell, the average programmer tends to only get maybe one flow block a day. Sometimes a really diligent programmer will manage two or three flow blocks a day, but that doesn’t happen very often from what I can tell.

Headphones, especially noise canceling headphones (like the ones I’m wearing right now), are an effort by programmers to block out interruptions and stay in a flow state.

With open offices, email, slack notifications, coworkers tapping you on the shoulder, and so on…

It’s almost impossible to get to a flow state as a programmer.

So, my advice to you is simple. If you are a programmer trying to maximize the total productivity and flow blocks each day, wear headphones, avoid meetings, don’t check email, turn off slack, and basically go into a cave and write code.

And if you don’t have the option to do that, accept the fact that you might only be able to get one flow block a day and plan accordingly.

How smart are your tweets?

beak-app

In a mere four hours of development, Johnny Lin turned an idea that was scribbled on his notepad into a web app that went viral almost instantly.

Beak is a new app that lets you rate how smart (or “un-smart”) your Tweets are using an algorithm based on the SMOG readability index. The app popped up last month and was quickly showcased by Product Hunt.

The app itself may be fun to play around with, but what’s interesting is Johnny’s post on Medium about how Beak’s success unraveled.

It’s July 4th and I just bought a 24 pack of Coronas with my roommates, and the three of us are hanging out in the living room. Two beers in, Rahul says, “let’s have a hackathon.” The thought of competition spikes my adrenaline. Let’s do it.

He goes on to ask his friend for “something bird related,” which is where the name Beak came from. While working on a prototype, Johnny evades his friends’ curiosity by not telling them what the app does until they drink “five more beers.” (If you’re not aware, that’s pretty much how hackathons work, except there’s usually a pizza or two involved.)

This is a fascinating story that will take you from idea to viral web app in just four hours. It’s definitely worth a read if you’re a web developer.

External Popup Links Using jQuery

With the deprecation of the target attribute in XHTML Strict, opening links in new windows has become a bit trivial, if not annoying, to standardize. I always look for a consistent, unobtrusive approach that degrades gracefully; and since I use jQuery quite frequently, this is how I usually handle them.

The solution is a small piece of jQuery code in your $(document).ready()section:

Now, add rel="external" to all of the links that you want to open in a new window:

From here on out, users that have JavaScript enabled will receive external pages in new windows, while those without JavaScript will still be directed to the appropriate location.

I use rel="external" because it’s generally a good practice to limit popup links to external websites only. You could very well use rel="popup"instead, but I prefer the former for semantics.

Escaping the Technical Debt Cycle

Most teams have some amount of technical debt. Others are crushed by it. It really shouldn’t be this way. For decades, we’ve been aware of good development practice. We know the things that we should do to avoid incurring technical debt and start paying it back. Clearly, something else is going on.

In this talk, Michael Feathers will explain the root cause of technical debt and the reason why it persists as a problem. There are solutions to the problem but they aren’t in the places we’ve been lead to expect – it is not just a matter of developing better and refactoring more.