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?
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.
After a relatively short time looking for a job, I joined my a new company: CodeValue. Specifically, I’m working on the OzCode project (which is awesome). But a bit later on that… First let me tell you a bit about my job hunt experience. Started looking for a job I got my CV ready and very hesitantly started to apply for some jobs. If you ever tried looking for a software job in Israel you probably know that almost all jobs are posted through personnel companies, and applying for one job means your CV will end up everywhere.
Have you ever encountered an over designer? An over designer is a software developer that had some life changing event and became obsessed about architecture. The result being, obsessive decoupling, endless coding of Factories, creating deep (also needless) inheritence hierarchies and various use of design patterns for no good reason. I believe the over deisgner is a mutation in the natural evolution of a software developer. Software Developer’s Evolution Not every software developer reaches to Senior level.