Top Developers Are Not Paid for Coding

TL;DR – There is this misconception that top Software Developers are appreciated due to their technical coding skills, for example how fast they can code a solution to a problem. While coding is very important, the real strength of top developers comes from understanding the domain of the problem they are solving.




The code should be the last thing on your mind

Have you ever interviewed a developer that when asked to solve a problem, they immediately approached the whiteboard? No matter how vague your question might be (purposely or not) they take their marker-caps off and start coding.

Unless the question is a well known algorithmic problem that you can learn by heart, there is only 1 possible outcome to this – you will stumble on every step of the way and you will probably NOT solve the problem correctly. And even if you do solve it correctly, it will take you much longer than expected.

This should be a huge red flag for every hiring manager or an interviewer.

So, my question is, why so many developers think that they are evaluated solely by their technical coding skills??


We learn the wrong things from others

We all try to learn from others and we all know that learning from other great professionals is the best way to advance your personal growth and your career. I think Louis Armstrong said it best: “If you are not the worst trumpeter in the band, you should find a new band”. And so we do. We change teams, we change companies, we alway try to find new challenges and top engineers to learn from.

My question is: are we learning the right things from those around us?

Lets take Jimmy as an example. Jimmy is a software engineer in your team. She is highly appreciated by her managers and peers. She gets her work done fast and her work is usually at top quality. She is what some may call a 10x-er. We want to be like her. We want to be like Jimmy.

When we look at her, what do we see? We mostly see her coding, and so we think to ourselves, hey, look how fast she is! She is so fast at solving this problem! I should try solving my problems as fast as she does! She is so talented and smart! I wanna be just like her!

But eventually somehow this doesn’t work. You get frustrated. You think that you are simply not that smart and you just don’t have what it takes to be at the top. You loose faith. You try coding your problems faster, but you keep stumbling and falling over and over again.

What you don’t usually see, is that there is another, slightly hidden variable with Jimmy. Turns out she only start coding when she understands the domain and the problem. If she doesn’t – she asks questions, she learns, she questions. She takes her time to understand the domain of the problem. She is looking beyond her code. She knows that the code is just a mean, not the solution.

So, in conclusion, Jimmy is not paid for coding. She is paid for thinking, for understanding the problem, for designing the business solution and finally, only at the end, applying he coding skills to implement the business solution.


What can I personally do better (my personal resolution)

The next time I am assigned to solve a problem, I WILL ask myself the following questions, and unless they are all answered with a YES – I will not start coding:

  • Do I understand what is the problem I am actually trying to solve?
  • Is the problem really a problem?
  • Do I understand the current state of things?
  • Can I explain the problem to others in a very clear way?

Sometimes the answers to these questions will make you understand that there is no problem, or maybe there are much simpler solutions to the problem at hand. In any way, you will most probably find the best solution to your problem.


Anyway, lets all be just a little bit more like Jimmy.













Posted in General Software, Uncategorized | Tagged | 2 Comments

Golang for the C# Developer – [2] The Environment

TL;DR – The development environment of a Go developer is very different from that of C#. All Go source code lives in a single workspace, there is no GAC and your machine Environment Variables play a main role in locating code, tools and binaries.


*I strongly recommend using the official page for installation and configuration.


To set-up the Go environment, all we need to do is to configure 3 environment variable:

  1. GOROOT – is the directory where your Go installation, docs, tools and Go standard library lives.
  2. GOPATH – is where you work, and where all your sources (and the sources you pull down) live. It is your workspace.
  3. GOBIN – is where your executables will be placed after you install a go program form source by running ‘go install’.

Assuming you are a windows developer, you should remember that as opposed to .NET, there is nothing like the GAC or the use of the windows registry for dependencies resolution. Your dependencies get resolved via those 2 environment variables.

Also important to remember that while in c# we can dynamically load a .dll assembly at runtime, in Go there is only 1 compiled assembly with all the dependencies compiled into it from source.


When you install the Go MSI on windows, the default location will be set to c:\go.


Now that we can find our workspace on disk, the workspace itself must contain 3 directories as follows:

  1. src – that is where your source and dependencies live
  2. bin – that is the location of installed executables
  3. pkg – is where compiled files live



I personally set-up my bin folder like this: %GOPATH%\bin. That way my go tools and installed executables are all placed in one directory that is easy to find.

After installing Go and configuring the mentioned environment variables, you are all set to proceed to your first helloworld example.


See also:


Let me know if got anything wrong in the comments below.

Posted in Go, Golang, Uncategorized | Leave a comment

Golang for the C# Developer – [1] Intro

TL;DR – In this series of posts I am exploring the Go (Golang) language from a C# native speaker’s perspective (or through one’s glasses). This introductory episode is more about the philosophy, history and general geekout over Go. You won’t see any code today. This series is sort of a personal library about my adventures with the language.




[The terms Go and Golang are interchangeable. If you want to know why there are 2 names for a programming language, try googling something with the keyword ‘go’]

Lets start with a riddle: what does UTF-8 encoding and the Go programming language have in common? Place your answers in the comments, and you may win a talking gopher-pet 🙂


History and philosophy of the Go language

I love learning and playing with new technologies, learning new programming paradigms and techniques. Lately I’ve been programming in Go, which is a relatively new programming language from Google. Go is young (2009), fun and very opinionated. After reading the book titled “The Go Programming Language”, tons of blog posts and all pluralsight videos, I fell in love.

I am a failing philosopher at heart. When I want to understand something, I need to understand the philosophy behind it. So what is the philosophy of Go and why it became so popular so quickly? Do we really need it? Is anyone actually writing production code with it?


Moore’s law and the rise of concurrent programming:

After decades of making processor chips faster, the reign of Moor is weakening – the advancements in processor’s performance is slowing down. Naturally, the software industry took a turn too: instead of concentrating on faster and faster processing of a single task, we are investing in concurrent processing of multiple tasks, maybe even on multiple processors. Concurrency became a common tool to boost performance and processing time of programs.

What is also natural, is that more and more tools have emerged to simplify concurrent programming. Lets face it, concurrency is hard. Threads are hard. Synchronization is hard.

Think about it, humans don’t get statistical data, so they invented pie charts and graphs. Humans also don’t get concurrent programming, that is where Google comes in with Go.


CSP and Actor model (feel free to skip to the practical parts below):

Concurrent execution and communication models for computers were researched years ago, the theories are not new. Some of the more popular academic papers were published in the 70’s and today are considered groundbreaking. 2 of the most notable papers are on the Actor model  [1973] and the CSP model [1978].

In the 21st century, with the rise of parallel computing and demand for concurrent programming, the classic and mainly academic papers became really popular and found their way to the mainstream of the practical tech world. Some of the manifestations of this are the frameworks and languages that emerged or simply became very popular in the past 16 years that are based on those theories. Here is a short list:

  • The Erlang programming language (CSP)
  • The Akka frameworks for both JVM runtime and .NET ( (Actor model)
  • Microsoft’s project Orleans (Actor model)
  • Google’s Go programming language (CSP)

So as we can see, the rise of Golang (and others) is just a natural turn of events. Go is inspired by the CSP paper mentioned above. CSP stands for “Communicating Sequential Processes”, and the original paper described a formal language for concurrent systems patterns and their communication based on message passing techniques.


The practical

So what do we have and maybe more importantly what don’t we have in the language?

Pointers – lets get this out of the way right now, Go has pointers, OK? There, I said it. Most of the people that are looking at my code, get terrified saying this looks like the C language, but the pointers in Go are very different than the ones we know from C or C++. It is not an easy task to shoot yourself in the foot with Go’s pointers. For example there is no such thing as pointer arithmetics, and returning a pointer from a function that points to a local function variable will not get you to those dark places where NullPointerExceptions live.

Garbage collected – although there are pointers in Go, the programmer is not responsible for memory management of his programs. Go developers don’t have to use manual memory allocations and cleanup.

Compiled to machine code – Go runs as a single binary that contains the machine code. There is no Go VM or anything like the CLR or JVM, and hence no JIT complication at runtime. This makes Go code extremely fast and performant.

Concurrent – Go has concurrency built in to the language. This is perhaps the strongest point to be made about the language. If you accept how Go deals with concurrency, your life will improve dramatically. I will go into more details in future posts to show you in more detail how simplified the concurrency reasoning is in Go.

Small and Opinionated – the Go language is extremely small. The number of language features and keywords is kept to a minimum. The creators of Go intentionally deny any propositions or requests for new features. There is only one way to do things in Go – and it is the Go way. No more holly wars over curly braces and loop structures. The biggest benefit of this approach is that the entry barrier for the Go language is very low. Reading someone else’s code is easy, and if you are new to the language, you will become productive in a relatively short amount of time. Go creators believe that less is more, and they have very compelling arguments for that.

No OOP – Go is not an object oriented language. There are no classes and there is no such thing as inheritance. However it is a statically typed language. The building blocks of a program are packages containing files, types, functions and methods. Go also supports interfaces (which I will cover in future episodes), however they are much more flexible than what we are used to with languages like c#.


Bottom line it is very different from C#, but very powerful and interesting. Barrier to entry is very low, and the language is very simple. There is a steadily growing community around the language and more and more software companies build products written mainly in Go. Check out the list of open source projects developed with Go on the language’s wiki page.

Try it, play with it, and checkout what Adrian Cockcroft has to say about Go and it’s popularity in new projects and products.

You are more then welcome to correct me if I got anything terribly wrong, the main motivation for these posts is to learn.

See you in future posts where I will look at the different features of Go, comparing them to their C# equivalents.


Shonn Lyga.

Posted in General Software, Go, Golang, Software Architecture, Software Concepts, Software Design, Uncategorized | Tagged , , , | 2 Comments

Self-Hosted Web Api testing with Owin/Katana

TL;DR – You don’t really need IIS to perform full automation testing to your web project. Today I want to show you how I am testing my ASP.NET WebApi services without IIS by using OWIN/Katana.

Download source code from my GitHub account.

(This article is targeting the pre .NET Core era).

Recently I was working on a project where I was developing a web service using ASP.NET WebApi (targeting .NET 4.5.2).

The main technologies that I used for the solution were:

After I was done with the main development (including unit-testing) I started thinking about how to go around the automation testing story.

As I consulted some of my developer friends (and Google), I was very surprised that the recurring theme was that they either don’t do full automation testing or they do, but only partially. Why? Most of them blamed the issue of hosting – in other words they needed IIS to host their WebApi service.

At this point I asked myself, do I really need to spin-up the IIS beast? Or can I somehow overcome that dependency and self-host my service? As it turns out, there is a pretty simple way to self-host your service in-process, without the need of any external web servers.

Enters: OWIN (Katana)

So what is this OWIN thing? Here is a short description from


This basically means that  you can build your OWIN implementation and use it to host your web project yourself, without the need for a web server (like IIS). The good new is, Microsoft already implemented OWIN in a project called Katana.

This meant really great news for my automation testing needs. I decided to take it for a ride, and so I wrapped the whole thing in a UnitTesting project and the rest is history.
Note that I also incorporated Ninject for Dependency Injection in the source code, that way you can also see how to provide dependencies for your api controllers during testing.

You can find a working template on my GitHub account. Simply clone the repository and run the unit test.


Shonn Lyga for PoZeCode.

Posted in .NET, Software Concepts | Tagged , , , | Leave a comment

DROP all you know about DB development (or: What is SSDT?)

TL;DR – I am using SSDT for developing a new SQL Server Database, and it changed my life. Everything is version-controlled, scripts are being generated automatically and DB deployment is finally a piece of cake. And SO much more. Using SSDT allows rapid iterations, while changing my Database as easy as my code. I finally have a full-stack solution where i can develop all my layers in one place, one flow and one source.

(The ideas and practices are general, but the practical tools are from the Microsoft stack: Visual Studio and SQL Server).



I was recently tasked with extending a legacy SQL Server database, and build a new Web Service on top of it. While planning my tasks for the upcoming sprint, I asked myself the usual questions:

  • How can I easily track my changes made to my DB schema?
  • How can I minimize human error when developing scripts for various DB changes?
  • How can I easily deploy my new DB?
  • How can I quickly iterate over and over again with rapid changes to the schema and stored procedures?


DB as code

All those points above got me thinking, why on earth won’t we love our Databases like we love our code? I mean, it is almost unacceptable to NOT use some kind of version-control for your code-base or NOT use some kind of an IDE with intellisense and code completion.  Moreover, it is becoming a global standard for teams to employ CI and CD practices (Continuous Integration and Continuous Deployment respectively).

So how come it is almost 2017, and we are still writing SQL scripts in notepads and deploy it manually to our DB servers? Seriously… Stop this cave-man madness…


Enter SSDT

SSDT stands for SQL Server Data Tools. It is Microsoft’s shot at solving ALL those issues I mentioned above and much much more.

Now that we got that out of the way, let’s dive deeper. SSDT is yet another project in your Visual Studio solution that will let you easily manage your entire SQL server locally and deploy the whole thing with 1 click. Ah, yes, for every change that you make in the schema or any other object in your Database project, SSDT will generate the appropriate scripts that will replay the appropriate changes on your server.

This seemed amazing from the get-go, however it’s power turned to be much greater. A game changer in our dev community, no less.


Projectify your Database

It is Monday morning, you had your morning coffee, you read this blog-post and decided it is a good time for some cool and quick experiment. To take SSDT for a ride, create a Database project in Visual Studio and see what happens. You will be amazed.

Create new project:



Now the important thing to notice here, is that along with the DB project in the Solution Explorer, there is a database instance that was automatically generated for you, and you can see it in the ‘SQL Server Object Explorer’.


Do you see what is going on here? You have a local Database in 3 seconds! That is all you need for your development.

Now you can add different Database objects (like tables, stored procedures etc…) and publish your project to update your local database. I hope you realize how amazing this is.

Lets add a table to our DB project:


Note that a beautiful designer opens up, and anything you change in the UI, will generate an appropriate SQL script that will be replayed later on your Database schema.


Now how do you update your local Database instance? Easy peasy – right click on the project node, and choose publish. You will get this window, so just choose your local Database and press ‘Publish’:


After 3 seconds, you should refresh your SQL Server Object Explorer and wallah, our DB is updated, and we see that we now are proud owners of a new table:



I am so excited, I can’t stress this enough! You now have an updated Database instance on your dev machine, local DB that you can program against and update the schema on the fly with friendly designers.

There are many (MANY!) other options and configurations like live Database debugging, advanced DB configurations, visual designers etc…  Almost anything you can do manually on your server, you can now configure with SSDT and the appropriate scripts will be generated in real-time, leaving you happy and filled with free time for the important things.


I will probably post more on SSDT in the future, but for now you can extend your knowledge with the following resources:


I hope you are excited as I am, and hopefully, we will all soon move to a new era where we treat our Databases as equals to our code 🙂

Shonn Lyga.


Posted in Databases, Uncategorized | Tagged , , | 10 Comments

What is Serverless Architechture

TL;DR – There is a server. It is not a “my-on-premises-Linux-box” kind of server, but there is one at the end. Perhaps it is just not yours and looks and feels a little bit different from the developer’s perspective.


server unavailable


The Buzz-Word

What would you answer if I asked you what is our industry best at? Well, I personally don’t know what we are best at, but we are definitely very good at creating buzzwords. The recipe for a perfect one would be to take some terms we all know and love, tweak them a little bit and use it to describe a completely different thing.

The new buzz-words in the industry today are ‘Serverless Architecture’. We can all imagine something when we hear our colleagues say the word ‘Server’ at the water-cooler. If you are a more traditional Desktop oriented developer, you probably think about a physical server-box that might be sitting in the next room. If you are a Web developer, you might be thinking about a Reqest\Response type of server that is running some server-side technology like ASP.NET or NodeJS.

In any case, when you hear ‘Serverless Architecture’ you probably think about an Architecture that has no Servers. So, are we back to rich client desktop application that only talk to a database? Or maybe the clients will talk between themselves without a server? Perhaps some new peer-to-peer oriented technology?

Well, that’s how you know that the new kid in town is misleading – it means something completely different from what it seems.


The General explanation

How we generally imagine our architecture:

client server arch


I am simplifying here in favor of clarity, but a ‘Serverless Architecture’ basically means that the server as YOU know it is gone. The server in general is still there, but it looks and feels a little bit different from the developer’s perspective. It is somewhat of a redefinition of the word Server.

Some may think that this is a natural turn of events. As in everything, we always have opposite forces that pull to other directions, but eventually, after a turmoil, we find an equilibrium in which those forces lay still. In our case in Software Architecture, there are 2 major forces – one that states that the “Server is God” and the other states “Client is God”. As with anything else, non of those forces are “correct” so to speak. The are many good reasons why for so many years the Server ruled the world, and now with the advancement in computing power and client side capabilities, we are shifting quickly in to the Client oriented architectures. In this new world the the server simply provides discrete, stateless functionality for the Client.

In the last 10-15 years we’ve seen the server becoming an external worker, sort of a contractor that provides discrete functionality for the Client. We migrated the business state of our applications from the Server to our Clients, so the server only comes in to play when the Client needs some specific functionality like Persistence, Authentication or heavy-weight calculations. The clear evidence is in the popularity of Microservices these days (another buzz-word, I know). So developers started breaking their monolithic Servers down to little independent pieces where each piece will perform a specific task (or a Service if you will).

Naturally, when one of the forces has its momentum, we are shifted to the extremes. In our case, the extreme is the ‘Serverless Architecture’. We decided that a Service is not a discrete or lightweight enough backend, so what is the next stage of diminishing the backend? The next stage is to break those services into even smaller pieces like functions. Yes, as in a function should become a service with an endpoint. It has an input, it performs a task and maybe emitting some output.

So we started by taking away the state from the servers, they became kind of one-time contractors per specific input. No state. Then, if the servers have no state and they only perform specific functionality, why should they exist as an integral piece of our system? Can’t we just break the functionality to a more granular level and then outsource that functionality to a third party vendor? We can. That is what ‘Serverless Architecture’ means.


BaaS vs. FaaS

Some of the literature out there is calling ‘Serverless Architecture’ different names with a slightly different meaning, but the general idea is the same – you should not write your server logic and maintain a server (or Service if yo wish), rather you can delegate that functionality to 3rd party vendors like Amazon, Microsoft, Google or any other vendor.

BaaS – Backend as a Service. The more popular use of this term would be with a Mobile backdrop, so BaaS becomes MBaaS. You basically develop your mobile application while using services like Firebase for real-time DB, AWS Cognito for Authentication services and so on. This type of ‘Serverless Architecture’ is not new, and many articles have been written around that topic.

FaaS – Functions as a Service. This is the new kid on the block. In this case you can consume server side functions without developing your own server, maintaining its code etc. You deploy business code, and that is the only deployed piece of software that you are responsible for. The rest will be provided for you as a service with endpoints.

So a Serverless application may look something like this:

serverless arch Fowler

(Taken from MartinFowler, I advise you to read the full article by Mike Roberts)


Pros and Cons


There is lots of literature out there regarding this, so i’ll just mention some key points:

If you need a responsive UI, you need to think twice before responding to user events by using FaaS because this will incur additional setup time for the remote function instance. Your function is not a server, it is not sitting around waiting for your request. Using FaaS in this case may present additional latency to your application.

On the other hand, if you are posting messages to a remote and asynchronous message queue, the FaaS provider may set-up a bulk of function instances to process your messages backlog and after it finishes processing the backlog, the function instances will be torn down.

Moreover, think about the DevOps effort that might be saved for you? All you have to do is deploy some kind of package to the server, and instruct the vendor to deploy your new function code. That’s it. The vendor becomes your DevOps guy on demand.


The Biggest Providers

So who are the biggest providers of Serverless functionality? Obviously, the biggest companies are up on the wagon.

You can also find many small firms starting to deliver services in that area.


Further Reading


Feedback is welcome!
Shonn Lyga.

Posted in General Software, Software Architecture, Software Concepts, Software Design, Uncategorized | Tagged , , | 2 Comments

24 – Jack Bouer vs. MSI

TL;DR – A ranting post about Wix and MSI packages




I woke up in cold sweat feeling terrified. I knew this day will not be a good one. I couldn’t explain why, I just knew…



I received horrible news this morning – I was assigned with a task to create a windows deployment package (MSI) that will install a server to IIS with a specific file layout and configuration.

At this moment I know nothing about installation packages on Windows, this is going to be an interesting day.



After spending an hour comprehending the horrible news, I figured I need to learn what the hell is a Windows Installer Package (MSI) and how do I go about creating one. I figured i’ll invest couple hours in an online course, so I went through most of this course on pluralsight (god bless the double speed streaming):

Wix Intruduction –



I think I am starting to understand what is going on.
Windows has a very old installation mechanism built in to it. To perform an installation, that mechanism needs an MSI package that contains all the information for that particular installation.

Oh, ok, but how do I create such MSI package?



There are several ways to create those MSI packages. The most popular way is to use WIX Toolset (no, not the web site creation wix). WIX stands for Windows Installer XML. So we use WIX to create an MSI that will be used by msiexec.exe to perform the actual installation. Phew, try saying this 20 times in a row.



Found some useful tools:

Orca – this tool enables me to explore the MSI file and see what is actually stored in it.
InstEd – this is like Orca but has additional features like MSI package diff between different version of MSI.



Assuming I have an MSI package, to install it with extended logging and debugging info, I should execute this with the following command:

msiexec /i mypackage.msi /L*vx  “c:\msilog.txt”












Nothing works… I hate Wix and i hate MSI, they ruined my life…



It worked!
It finally worked!
I love Wix!
I love MSI!



Time to unwind, have a cold beer and watch a good TED talk



All in all it was an interesting day…
Good night…



Posted in Uncategorized | 6 Comments