Munich Startup Meetups: Ringside Talk #2

It has been a whole year since I moved to Munich, but the opportunities that the city offers still don’t stop surprising me. Indeed, the startup community here may not have the media hype and the vibe of its Berlin counterpart. Yet, it is growing steadily, building a strong ecosystem of new players, backed up by and learning from the success of larger enterprises. An ecosystem, where teams help, and not mindlessly copy each other. An ecosystem, where people with various backgrounds and experience meet up regularly, exchange ideas, and most of all, have lots of fun.

A couple of days ago, I took part in Ringside Talk #2 – a super-sped-up version of the Google Design Sprint (GDS), organised by the local chapter of Founders Fight Club and hosted by PayBack. The idea of the GDS is to cut short through the processes of building and launching a product. Instead, a product idea gets brainstormed, and continuously revised over a series of interviews with different groups of people. What normally is supposed to happen in 5 days, we had to do in one evening (i.e. a little more than a couple of hours), starting shortly after everyone finished work. A few hours later, we had already scoped the problem down to a concrete idea, had put it through a series of feedback interviews, and were ready to pitch it to investors and the jury.

Bringing an idea from nothing, to something ready for pitching in that little amount of time is not easy. More so, when you don’t know some of the other members of your team. You choose a topic, quickly get to know your teammates over some pizza and beer, and off to the job. All of this made it so much fun though! All one needs is relax and accept the challenge. When each of the team members is equally ready to participate, a team spirit forms within minutes. The rest is hard work and fast reactions.

Our team did not win the first place, but we won nonetheless. I met many new friends, with whom I’d gladly consider potential ideas for future work. I also refreshed my pitching skills, and my ability to generate ideas under pressure. The past year has been quite intensive for me, with lots of hard work on many projects, but primarily on the deep technical side of things. It felt great to envision future ideas from scratch again. It was some sort of a spiritual comeback for me. I hope that challenges like this one would help me finally put into motion some of the many projects, I have been working on in my spare time.

All in all the Ringside Talk challenge was lots of fun, and I am looking forward to taking part again!

Thanks, Jan and Patrick! Also, thanks to my teammates! We should all grab a beer sometime soon again 😉

At last, a few photos, to give you a real impression of the event. You can also see the full gallery here.

Photo credits to the guys at Founders Fight Club.


Don’t Have Time to Read? Listen!

Cover Photo Credit: Pixabay

It’s funny. We live in the age of unlimited available information, and yet, it seems to me that our reading attention has been falling through the floor during the past few years. Don’t get me wrong. Nowadays, we obtain more information on a daily basis than ever before. Thanks to the Web and mobile revolution, the world’s knowledge now fits into a tiny block, the size of your pocket. Reading is easy, you say. All I have to do is open up Pocket, and the 5-minute train delay gets fulfilled with scrolling trough the latest and hottest Medium articles. Yet this is still not my point. What I am hinting at, is long-term reading. When was the last time you really, really felt so engaged into reading, that you forgot how the last few hours slipped away?

Yes, I know, who has the time to invest in long-term reading nowadays? We are busy — always on the go, hectically switching between means of transportation, or at the desk, heavily focused on the current activities at hand. The last thing on one’s mind at the end of a tough day at work or school, is yet another couple of hours of intense eye strain.

Much of what we do on a daily basis does involve reading, but of a different sort. We read with lesser intensity, a lot of interruptions, and switching of sources. While reading, we are less involved into the detailed descriptions, but rather focus on getting the gist of what we are reading, in the shortest period of time. This form of reading, also known as “skimming”, has been preached by schools and universities across the world for several decades.

From a practical point of view, skimming seems like an efficient way of getting things done quickly, and is therefore praised by the modern world. Our generation’s almost innate ability to skim through different sources of information, is probably one of the lesser known reasons why we have adopted mobile technologies so quickly. Mobile devices, with their limited display form factor, were designed for conciseness of the interaction, which app makers were quick to explore to new heights, and consumers instantly fell in love with.

Yet, as much as we tend to convince ourselves that modern inventions have made us more informed, the opposite is true. In fact, we are switching through sources faster than ever now, spending mere seconds on each one, before moving away. This has a negative effect on our thinking, leaving the brain in a constant state of confusion and alertness, which forces us to keep switching the context. No wonder why multitasking almost never seems to pay off in the long run.

Timeout

Time to take a break, move your eyes off your phone’s screen, and listen. Literally! What if I told you that you can be just as informed and up-to-date, if you switched to obtaining information by listening rather than by reading? At the same time, your attention and concentration will improve, but not at the expense of your mental exhaustion. In fact, the more information you manage to obtain by listening, the more relaxed you will feel. Once you free your eyes from the constant focus, you might discover a whole new world of opportunities to check out, while listening.

This can’t be possible, right? Well, it actually is, and I have experienced it for myself. I have been practicing active listening for about a decade now, and I try to recommend it to everyone I know. It works! Ironically, the main reason it actually works, is because listening lacks the one thing that we have been taught to perfect over the years of schooling — skimming. Unlike reading a text, while listening, your brain is focused on what is happening in the particular moment. Your ears can’t hear what has been already been said, neither can they foresee what is about to come.

I know that this sounds a little limiting, as if you’re being forced to slow down the pace of your brain. In fact, though, the opposite is true. After just a few hours of practice, your brain will get used to the pace. For the first time in years, it will actually start paying attention to what is being said, without instinctively trying to force you to skip forward or change the topic. Don’t be scared if you start asking yourself questions and immediately formulating their possible answers. Increased curiosity is a positive sign of a fresh and focused mind. Remember, it is not about how deeply your mind focuses on thing. It is all about how often it switches between unrelated things.

Though the amount of audio content available online is nowhere near that of written text, it is seriously getting there. The following sections are supposed to give you a few tips on how to start. If you have a natural aversion to listening anything other than music during your morning commutes, I’d really recommend you to give podcasting a first try. Once you bring the back the habit of obtaining information by listening, audiobooks are the next step. Lastly, to completely break you away from any limitations of available audio content, my secret tip for advanced listeners: text-to-speech (TTS).

Podcasts

Podcasts are the easiest to start with, because they are readily available, short enough to start with, and cover a large variety of topics to choose from. When I say large, I mean, literally thousands of great shows to choose from, and tens to hundreds of new ones coming up every day:

Podcasts come in a large variety of topics
Podcasts come in a large variety of topics

Podcasting has had its ups and downs, but it has definitely matured during the past couple of years. It has outgrown its traditional garage roots, and come to a point, in which professional journalists and radio hosts have helped evolve the media, and bring some shows to a Hollywood-level state of fandom. Unless you have lived in a cave for the past two years, you must have at least heard about Serial. You may as well have followed Alex Blumberg’s first steps in building a profitable business model out of podcasting. His hard efforts in the first season of “StartUp” have been rewarded with the birth of Gimlet Media — his own podcasting startup, currently producing tons of great audio content. Last but not least, I can’t help but mention Leo Laporte and Jason Calacanis for their ongoing efforts to establish podcasting as a de-facto standard in reporting tech news over the years.

My current TOP 10:

  1. This Week in Tech (TWiT)
  2. StartUp
  3. This Week in Startups
  4. Fragmented — An Android Developer Podcast
  5. a16z Podcast
  6. TED Radio Hour
  7. The Unmistakable Creative
  8. Song Exploder
  9. Note to Self
  10. The Pitch

and many, many more …

Audiobooks

Once you have made the first step, it is time to put you on the lengthier track — audiobooks. Unlike podcasts, audiobooks are way lengthier and might require a few interruptions until you finish the books. Generally, they will require a fair bit more attention from your brain, but hey, consider the actual benefits of listening an audiobook. You are actually “reading” (yes, I know) a full-blown book! Taking aside the ones you’ve barely skimmed through, and the ones you could not finish due to eye fatigue, how many books did you really manage to really read last year? An audiobook is being read to you by a professional narrator — usually a voice actor. Sometimes the narration is so engaging that your brain plunges back into the fictional story line mere seconds after you have pressed “Play” again. Yet, unlike reading an actual book, your eyes are free, so the opportunities to enjoy an audiobook are much more. I figured out for myself that I have started walking much more, ever since I discovered audiobooks. I hope that it works for you in mutually positive ways.

Granted, professionally-made audiobooks are not free, but doing the math, they are not that expensive either. Companies like Audible already offer more than 150.000 titles, and thousands of new ones coming every month. Sometimes, even before their printed editions. In all honesty, I’d love to see a little bit more competition in the market (Audible has pretty much dominated it for years), but I’m sure that this will happen as well.

TTS All The Things

Now, my advice for those of you, for whom listening has already become an essential daily activity. Text-to-Speech Synthesis (TTS). Wait, what, the dorky, metallic robo-voice generator? For those of you, who have last heard TTS, when it sounded a bit a-la GameBoy soundtrack, I have some news. The technology has long since evolved, and with it, the monotone, 8-bit sounding. Today’s voices vary not only in pitch and intonation, but also also capable of speaking with a particular dialect and show emotions depending on the mood of the text being read. If Siri has not been able to convince you, you should check out the Google Assistant’s voice, or my personal leader in the genre: IVONA. Sadly, to my knowledge, IVONA is only available on Amazon devices, though if you are an owner of a Kindle tablet or Alexa, you already know what kind of quality I am talking about. Besides being cheap as hell these days, the only other reason I got myself one of the Kindle Fire tables, Amazon has been so eager to get rid of, was IVONA. Being able to listen to my hundreds of books in text format, has been lots of fun so far.

Pocket already fully supports TTS
Pocket already fully supports TTS

If you want to try the power of TTS first hand, I would recommend checking if your favourite reading apps already support it. Many even do it, without you having the slightest idea about it. Pocket is one great example. In fact, for the past year, I have almost exclusive TTSed most of the articles I’ve got on my Pocket reading list (unless they contain some source code). Just as with podcasts and audiobooks, TTS may take some time to get use to, but please try it. After the first few minutes of slight confusion, you will afterwards not even notice that a machine is reading you an article, and not a human being.

Further Reading

Neuroscientists say multitasking literally drains the energy reserves of your brain

Does your morning routine consist of checking emails, browsing Facebook, downing coffee, heading to the train while Googling one last idea, checking notifications, more coffee, and going through your work email? The myriad activities crammed into your morning, and the constant switching between them, is likely making you very tired.

The web has stolen my creativity. I need the time and space to think …

I have an admission. A declaration, maybe. I’ve had to step off the world for a few weeks. It’s all spinning too fast, and there’s no place to rest, no island, no solace, nowhere to spare a few hours passed out between a battle to fall asleep and being woken again long before dawn by a tornado child.

Want to learn faster? Stop multitasking and start daydreaming

Information is being created and disseminated faster than any of us can absorb it. Google estimates that humans have created more information in the past five years than in all of human history – 300 exabytes of information (300,000,000,000,000,000,000) to be precise.

Android Developer Links (July 2016)

Photo Credits: MKBHD

Articles

047: Custom Views & ViewGroups with Huyen Tue Dao – Fragmented

In this episode we talk to Trello engineer, GDE, YouTuber, Caster IO instructor and View magician Huyen about all things custom View/ViewGroups.

Exceed the Android Speed Limit! – Google Developers

When it comes to goals or benchmarks for app performance, there is really only one. Does your app consistently draw the screen fast enough so that your user sees smooth, fluid motions, transitions, and responses? It turns out that for that user experience, your application has to do all its work in 16 milliseconds or less for every single screen refresh.

Android Development: some of the best practices. Jun 2016 edition

Use Kotlin, yeah it’s time! Consider it long term investment in your project and skills.
Think twice before adding any third party library; it’s a serious commitment.Use only small, one-feature libraries and abstraction layer above it — would be easier to replace in future.

Instagram + Android: Four Years Later – Instagram Engineering

The first version of Instagram for Android was built in four months by a team of two engineers. It’s been four years since that launch, and in that time we’ve added features such as video, direct messaging, photo maps, advertiser support, and new ways to discover and explore the amazing content shared by users around the world.

Introduction to Kotlin: Android Programming For Humans

Java has been a dominant programming language for ages, but modern times call for modern languages. Meet Kotlin, a modern, clear, and expressive programming language powered by the same virtual machine technology that powers Java.

Create Intelligent, Context-Aware Apps with the Google Awareness APIs | Android Developers Blog

Last month at Google I/O 2016 we announced the new Google Awareness APIs, enabling your apps to intelligently react to user context using snapshots and fences with minimal impact on system resources. Today we’re proud to announce that the Google Awareness API is available to all developers through Google Play services.

Code and Libraries

beworker/featured

Simple yet powerful composition library for Android

Kotlin Basics: apply() and copy()

Without any doubt, Java is a verbose language. This verbosity of the language makes it easy to understand Java code by new programmers. It is though one of the reasons, why many Java programmers find writing Java code tedious. Kotlin brings a touch of succinctness in places, where even programmers new to Java, may find code unnecessarily over-bloated.

How many times have you had to do the same thing over and over again:

Having an object, you want to modify some of its properties and simply return the same object. In Java, you can’t do this in a single chained fashion. In Kotlin, you can squeeze the above method to the following single line of code:

apply()

By definition, apply accepts a function, and sets its scope to that of the object on which apply has been invoked. This means that no explicit reference to the object is needed. Apply() can do much more than simply setting properties of course. It is a transformation function, capable of evaluating complex logic before returning. At the end, the function simply returns the same object (with the added changes), so one can keep using it on the same line of code.

Note: Please, note as well the direct use of properties instead of explicitly calling getters and setters. This is not a bad practice, since Kotlin implicitly invokes provided getters and setters of a property, when working with the property (similar to C#).

copy()

Please, remember that using apply on an object is NOT a thread-safe operation, and mutates the state of the object. If you want to retain the original object and return an immutable copy of it, you can use the function copy(), provided in all instances of data classes.

Assuming that your class contains only data (usually a good practice to separate logic from data), you can turn it into a data class:

Data classes have a few advantages, and one of them is definitely the copy() function, provided to each and every instance. It not only provides a copy of the original object, leaving its state intact, but also allows setting new values to some of its properties at copy-time:

Kotlin supports named parameters, known from other languages, such as Python and Scala. In this case, they make life much easier, as all you need to do, is specify the name of the particular property (or properties) you want to modify by copying.

At the end you can combine the power and succinctness of both apply() and copy() by calling apply after copying:

Dev Ergonomics Tip: Use a Dark-Style GitHub/StackOverflow Theme

As many of the developers I know and have met, I am also used to using a dark colour theme on all of my IDEs and text editors, and the command-line terminal. In fact, if an OSX app (still hard to get used to saying macOS) supports a dark mode, I’d most probably turn it on, to avoid the sharp contrast when switching between my work environment and other applications. One thing that has often irritated me though, has been the switch between my IDE and two of programmers’ go-to websites: GitHub, and StackOverflow. Both feature a completely white background, which has required a brief period of eye adjustment, every time I switched away from my IDE/editor. Well, until today. Turns out that there is a single dark theme for both websites that can be installed through a browser extension, called Stylish. Stylish supports Firefox, Chrome, Opera, Safari and Firefox Mobile, so you should hardly have any problems installing it. Once you have it installed on your browser, go to each of the following links, and install the respective styles for GitHub, and StackOverflow:

GitHub dark styles

StackOverflow dark styles
After installing the styles, refresh the respective pages, and they should then look this:

GitHub dark theme

StackOverflow dark theme

Dark Style Source Code:

https://github.com/StylishThemes/GitHub-Dark

https://github.com/StylishThemes/StackOverflow-Dark

 

Kotlin Basics: Create Executable Kotlin JARs, using Gradle

Kotlin is great for creating small command-line utilities, which can be packaged and distributed as normal JAR files. This short tutorial will show you how to:

  • Set up a Gradle project that supports Kotlin
  • Add a starting function
  • Configure your build to call this function when you execute your JAR.

Setting up Kotlin dependencies

You will also want your IDE (I assume you’re using IntelliJ or Android Studio) to mark the directory where your Kotlin source code resides as a source directory. Since Kotlin and Java are best friends, it is perfectly fine to keep the same package structure. It is a good practice though, to keep your Kotlin code physically separate from your Java one. Thus, you’d typically have two folders under srcsrc/main/java for Java classes, and src/main/kotlin for Kotlin ones. Same for tests. Again, in your build.gradle file, add the following:

Using IntelliJ, you could rely not he IDE to guide you with all of this, but I wanted to show you the basics, since one may not always rely on the comfort of an IDE. To see that everything is working as it should, go to your project directory and create a new build:

If everything has been set up correctly, you should be able to see a task named compileKotlin which the build has executed successfully.

Write your first Kotlin program

Unlike Java, Kotlin is friendlier with functions that reside outside of any class scope. You can create a Main class hosting a main() function, or you can create a top-level main() without necessarily wrapping it in a class. Perhaps, you wouldn’t be able to find any difference in a such a brief examaple, but I find the possibility to create top-level functions helpful in reducing boilerplate code.

Here is the mandatory HelloWorld example. Create a file with an arbitrary name (say Main) and an extension .kt, and write simply:

Note that adding a package is optional, as well as ending your lines with semicolons. In order to keep consistency with my Java code though, I’d usually add both, and expect that people I work with, do the same.

Configure your Gradle build to create an executable JAR

The main function we just added, is enough to test setting up an executable JAR, which one should then be able to call simply by executing:

If you simply try to build your project and then execute the above command, we would get the following message:

This means that we have to configure jar task, which Java Gradle builds go through, and tell it which the starting point of our project is. In a Java project, this would be the path to the class where our main() function resides:

Wait a minute? We have defined our main() function outisde of any class scope. That’s true and not entirely true at the same time. Actually, to keep things at the bytecode level consistent, and backwards-compatible with the JVM, the Kotlin compiler adds all top-level functions to respective classes. In our case, the class generated by the Kotlin compiler would have the same name the filename of the file where our function resides, plus the suffix Kt. This means, for example, that if our file is called Main.kt, the Kotlin compiler would generate a class with the name MainKt.class and add it to the generated JAR file. Knowing this, one could rewrite the Gradle configuration above, as follows:

Note: You can specifiy the name this class should be compiled with, by adding a file-scope annotation on top of your file, even before the package decalration:

This new name can be used within the JAR manifest configuration, as shown above.

Even though we specified our main class correctly in our JAR manifest configuration, if we try to execute our main function using jar -jar, we will still see an error message:

Experienced Java developers will quickly recognize this type of exception. By default when Gradle (as well as Maven) packs some Java class files into a JAR file, it is assumed that this JAR file will be referenced by an application, where all of its dependencies are also accessible within the classpath of the loading application. To execute a JAR without having to specifiy the path to itse dependencies, one must tell the build system to take all of this JAR’s referenced dependencies and copy them as part of the JAR itself. In the Java community, this is known as a “fat JAR”. In a “fat JAR” all of the dependencies end up within the class path of the loading application, so code can be executed without problems. The only downside to creating fat JARs is of course their growing file size (which kind of explains the name), though in most situations, it is not a big concern. In order to tell Gradle to copy all of a JAR’s dependencies, one should simply modify the abovementioned JAR task configuration, by adding the following piece of code:

Further Links

Kotlin Basics: Named Parameters and Default Arguments

Named parameters and default parameter values

Similar to their equivalents in Python and Scala, functions in Kotlin can have named parameters and default parameter values. This makes it easy to provide an arbitrary order of params, by specifiyng them by name. It also allows for skipping certain params altogether, when we do not need to specify them. When declaring a function, this leads to less overhead with overloads. Check out the function joinToString(...) provided to all collections:

when you only want to add values to one or two parameters, you can do like so:

via
Default Arguments
Named Parameters

The Role of the Full Stack Developer in Large Projects

A little less than two decades ago, things were simple. Software developers were primarily engaged with developing software end-to-end. There was no major distinction between the people creating the UI, and those developing the backend. Most applications were either desktop monoliths, or desktop “clients” that communicated with some kind of server backend, over the network:

A typical Windows UI
Photo credits: Microsoft

In either case, early development tools provided enough building blocks, for developers to create everything under the same project. This resulted in homogenous, but boring, and unappealingly looking applications. Back in those days, Web was, for the most part, a bunch of static pages, linking to one another. With some eccentric exceptions, most of them resembled the look and feel of their blocky Windows counterparts.

A few years later, during the early and mid-2000s, came the Web 2.0 revolution, which swept everything away. Rather than remaining single-purpose monoliths, software applications turned into distributed “services”. The traditional model of installing hundreds of megabytes on one’s computer, got replaced by typing the URL of one’s favourite web app in a Web browser. With time, the relevance of the underlying operating system diminished. In a little less than a decade, the browser became the OS — for many, the one and only window kept open at all times.

Web 2.0, and the following foray into mobile, forced significant changes, into how the new wave of software applications was supposed to be built. For once, backend and frontend development became separate disciplines, each requiring a different set of skills and expertise. In fact, in recent years, the gap between frontend and backend has become became so huge, that a new discipline has arrived, intended to glue those pieces back together — the role of the full stack developer.

Misconceptions

If you look at job listings nowadays, it seems like just about everyone is looking for developers who can work on all aspects of a project. Many companies call this a “full stack” position, and in fact many organizations already have opened such “full stack” positions across their teams. I find this idea of a “full stack” developer being a “know-it-all” whiz, flawed, and dare believe that relatively few organizations have managed to raise the new role to its full potential. This post tries to shed some light on where the full stack developer should ideally stay within a team, hoping to help dissolve those misconceptions.

There are two very contradicting misconceptions that get tossed around, when it comes to defining what a full stack developer is, and the full stack is supposed to do:

The full stack developer knows a bit of everything, so our company will save on human resources, by hiring a few of them.

or

The full stack developer knows a bit of everything, but nothing in particular. A full stack developer would only be a burden for our team. She would never be able to go into the the level of detail, the way a frontend, or a backend guy would do.

Neither of these is 100% wrong, but neither is correct either. A full stack developer is not a whiz kid, who could magically replace a team of backend and frontend experts. No. Though a full stack developer is supposed to understand both worlds, her role is not to replace, but help bring those two groups closer together. In fact, a good full-stack developer is a bit like the bass player in a rock band:

Flea from Red Hot Chili Peppers.
Flea from Red Hot Chili Peppers. Photo credits: Wikipedia

##Full Stack = Bass Player?!?
Playing bass in a rock band is an often underrated, but an incredibly important role. Unlike the vocalist or the guitar player, the bassist takes little credit for her performance. With the exception of jazz and funk music, the bassist rarely does have a prime time on her own. She won’t always pull out a breathtaking solo, the way the lead guitar would do. She also won’t always engage the fans, the way only the vocalist could do. Yet, a good bass player will always be there, gluing the entire band together.

“A bass player is a bit like the mortar between the bricks.” (David Elefson, Megadeth)

Have you ever seen a good rock band with a bad bass player? Or worse, a self-respecting rock band with no bass player at all? No? Well, there are a few good reasons for this:

First of all, there is a huge sound spectrum gap between drums at the low end, and high-pitched guitars and vocals at the other one. This gap is usually filled by the bass. Taking the bass out of the equation, leaves a shallow tune, left of “soul and spirit”. You can still listen to it, but it will always feel as if something is missing.

Having a skilled bass player in the band though, is just as important for the other band mates, as it is for the audience. One of the hardest things in playing in a band, is playing in tune and sync with the others. This is where the role of the bass player as a coordinator and a hub between the players is so important. She keeps the tempo and rhythm set by the drummer at all times, laying out a foundation of the main melody, which stays pretty much the same throughout the song. This allows the guitar player to pull off a beautiful solo, without fear of the sound breaking loose.

##Back to the Team
A software team nowadays, looks pretty similar to the rock band, I have been describing so far. You usually have pure backend and frontend developers, covering their own spectra of tasks. If the project at hand is well specified, both sides typically agree on an API and keep doing what they do best, sharing little concern of how the other side is doing things.

As we all know though, very few things in life work in their ideal state. Much of the time, developers spend clearing out the misunderstandings in their communication. They do this at lengthy meetings. If you have been in such a meeting, you know how little respect a frontend guy would pay to your detailed proposals for speeding up the backend. Let’s be honest though, when it comes to frontend guys explaining their problems, it’s your turn to start looking at your phone. That’s just the reality. More often than not, the visions of the two sides deviate, and the only way to bring them back on track are more meetings, and refactoring efforts.


This is where introducing a full stack developer to the team can be a huge boost for the team’s productivity. Not necessarily in terms of bringing new features to market, but more in terms of reducing team friction, and cutting down the refactoring efforts.

The full stack developer can understand the concerns of both sides, and translate them into code that takes the input from one side, and makes it easy for the other to process. In large projects, this usually involves the creation of a thin layer of abstraction that sits between frontend and backend. This layer, also known as “middleware”, should hide the implementation details of both frontend and backend, and provide a seamless flow of data from one end to the other.

Where developing a middleware traditionally assumed using the backend technology stack, I have been seeing a shift towards bridging the gap even further. It is not a surprise, to see a mixed stack on the server, where the core backend might be Java-based, with a middleware sitting up front, based on NodeJS. For large software projects, pulling off such a feat can have the effect of skyrocketing the project, or bringing it down to earth, if done improperly. This is one place, where having a team member who is proficient across the entire stack, can make a huge difference.

Not only that. Full stack developers can be the drivers of new feature development. Though one can hardly develop a new feature across the entire stack alone, it makes sense to let full stack developers build a scaffolding, which backend and frontend devs can later work on. Again, this can save time and communication effort early on, as well as refactoring efforts later on in the project.


As you see, the role of a full stack developer in a large project is far from being the expert or the whiz kid who can do everything. Similar to a bass player in a rock band, the role of the full stack developer is much more the one of a communicator and coordinator between frontend and backend. It is not meant to replace any of those roles in the nearby future, but rather support them, and build bridges between them. I hope all of this makes sense to you too, and you will take it into consideration, the next time your organization decides to bring a full stack developer on board.

Disclaimer: I am both a full stack developer and an avid bass guitar player 😉


This blog post was originally posted on my Medium page

FIX: Angular2 – Missing Http Observable.map Function

The first Http example that most new Angular 2 users get to try their hands on, is this code snippet taken from the Angular 2 Http Docs:

What the documentation fails to mention though, is that besides subscribe, other Observablemethods, such as map, for example, need to be imported separately. In the case of map, adding the following import statement at the top of your class file will fix things:

What I find a little irritating, is the slowness, with which Google usually updates documentation pages of the open-source projects. For this one in particular, there is a pull request on GitHub, submitted almost half a year now. Please, Google, do us all a favor, and keep introductory documentation pages, up-to-date!