I’m sure every software engineer with a long career had this dilemma: Should I join a startup or a big corporation? It’s a good question since your professional development, the working conditions, life-work balance, and career development will be very different according to the choice you make. There are many differences between a small company and a big company and it’s important to understand them in order to make the right decision for you.

Office politics always sounds kind of negative, right? Like that bad side effect that you have to suffer in your job. Or like a constant obstacle to any good thing that you can achieve. I don’t think I ever heard someone say “I enjoyed the office politics in that place”. Somehow, when a company surpasses a certain amount of employees (say 30), office politics becomes a thing. All of a sudden, instead of every employee in the company having the same goal in mind, the various teams develop individual goals.

One of the most important things in a good project is naming. You can’t deny it – Good names of Modules, Classes, Methods and Variables can make the difference between a code that’s a joy to read and obscure text. Some names are so bad that every time I see them I get a little jolt of annoyance bordering pain. I mean, I worked so hard to build this beautiful piece of code, this piece of art really and it’s now completely ruined by this… Name.

Did you hear about stackshare ? It’s a pretty neat website that I recently discovered. The idea is that you can search for any tech company, and see their technology stack. For example, here is Airbnb’s: So the first interesting thing that came to mind was checking out what the most successful startups are using. I used this list of “successful startups”, in addition to angel.co startup database. After looking at about 100 startups, I ended up with data from 23.

In the modern world, we are dependent on dozens of libraries. These in turn, depend on dozens more and we end up with hundreds or thousands of dependencies. So now the problem arises for a single application. What to do when several of its projects depend on different version of the same assembly?

In software we have to learn new technologies all the time. I mean, every day there are probably a couple of additional JavaScript frameworks born into the world. The amount of languages, frameworks, 3rd party libraries and tools is staggering. And every place of work uses a unique permutation of those. As developers, we have to stay on top of things, no two ways about it. Once we’ve decided we want to learn a new technology, we have a lot of ways to approach that.

How the annual review scores are formed in the eyes of managers always fascinated me. I have five years of experience with annual reviews myself, and I was always able to do well on them. As a tech lead, I got to give recommendations and participate in some discussions with managers. I formed a pretty firm and possibly naive point of view on them now. The process The way the process went in my last company, and I suspect in most big companies, is like this: At year’s end, the employee is asked to fill out a long form about his achievements and goals.

Did you ever feel like Visual Studio is rebuilding projects every single time, even when there were no changes to the code? We can build, change nothing, build again and there we go… VS is starting a build instead of saying all my projects are up to date. Also, there’s that nagging feeling that even when we do change something, VS is building way more projects that it needs. Like most things I do in life, frustration led me to look further into this matter.

After working for the last three years with TFS’s classic source control TFVC, I recently moved to a new company and with that, to Git. Before working with Git, I loved working with TFVC. I thought it was great and pretty much the most I can expect from a source control. Git, however, changed the way I work with source control and even the way I think about source control.