This post is at least 1-year old and it was originally created when I was about to start a new job. I have made an initial list of around 40 points which I wanted to follow and here is the first “high-level” part. I am a developer and the view in the answers is based on my technical background.

1. Get to know the company’s business model and values

Your new workplace has a certain vision and your first task is to adopt it.  Early understanding of “theirs” way of thinking and values will make you more efficient from the beginning. Talk with someone on a “higher position” in the company to get the best source of information about this topic. Someone as a CEO should perfectly know where the company is steering now and what is they are doing as a business. Maybe, you will not be able to speak openly and directly about this with your CEO, but you know it… the higher the person you ask is, the better and more clear answer you will get.

2. Get to know the company’s goals in the near future (the next 1-2 years)

For sure your new working place has a development plan for the next years. You have to understand it and prepare how you can do your part from it. Obviously, the things will be not so simple, but broad understanding of the topic will be sufficient. Further, you need to assimilate this plan to what you will be doing in the future. Some working places are using a result-oriented model like the OKR model by Google where every layer of employment depends on the goals of the previous top level of management.

3. Get to know the departments and the positions in the company

Knowledge on this issue will be beneficial to understand the corporate ladder and to manage easier your way through the company.  Not only this, but this will help you to get help and work done much easier. Pay attention to the departments with which you will collaborate closely. What about if your company does not have departments? Yes, sometimes this is done by one-man army departments but the overall tendency is to exist separation of the duties in the working place.

4. Get to know the company’s global work process

As a company, you have to expect that your employer has already managed to create its own unique working process. This topic should include how the bids are done, through the design and to how the product is delivered. Learn it and pay attention to the phases where you are entitled to take action and responsibility.  The global process will help you to understand the business and to be part of it.

5. Get to know how to solve specific administrative matters

No one wants to lose time or energy to solve specific administrative tasks. Learn the required workflows from the beginning to optimise the process. This could be e.g. how to send a request for a holiday, how to register time, where to claim expenses and so on. The bare minimum is to know the email of the accounting department and the contacts of the system administrator. 🙂

Tip. Get to know your perks as an employee and ask your colleagues if they use them.

6. Get to know the other developers in the team

Your peer colleagues will be your most important friends from the beginning. You will work with them daily and your goal is to build a strong team with them. Play nice with them and this will reward. Don’t be afraid to ask stupid questions. They know why you are here and they have been in your situation. Make sure you get to know everyone personally from the beginning. Understand the team dynamic and how they fit as a group. Remember from the beginning their names, show respect and show a mixture of curiosity and desire to learn everything new they will present to you.

7. Get to know the development environment and the technology stack (including installation and running of the environment)

Here you need to pay attention. This will be crucial for your further development in the company. Make sure you understand the stack and can support it. You should know how to install and work with all tools related to your job. It is an easy win if you have to fix some of the guidelines, Wiki pages etc.

8. Get to know the product portfolio baseline and any specifics related to single customer projects

Understand the product and the portfolio of the company. Probably this is one of the reasons why you are joining them. You like the product and you see the future for it. Understand the business logic and business cases for the product of your company. If the product is custom-tailored for some customers you have to know the differences from the beginning.

9. Get to know any specifics/pitfalls/traps related to this type of business/software from developer point of view

Like everything in life, there is a good and bad side for a thing. Get to know what are the problems, the specifics for your type of work. Ask actively the folk around what they think that it is a problem or a challenge in their work.

The exam 70-483 (Programming in C#), https://www.microsoft.com/en-us/learning/exam-70-483.aspx, was released a long time ago. Just recently I started to look into possibilities for professional certifications (mainly because it was requested by my employer). My final goal will be the MCSD (Microsoft Certified Solution Developer) certification https://www.microsoft.com/en-us/learning/mcsd-certification.aspx. Part of this certification path is the mentioned exam. In the short post, I will explain my experience with the exam.

I am using C# on a daily basis and in my opinion, this should be enough to take this exam. Nothing else on top of it is needed.

Actually, Microsoft is expecting that the ones taking the exam have between one and three years of working experience with the language. There is nothing more on top of this, it is just mentioned in the section “Who should take this exam?” and also on the exam survey during the real exam.

First about the preparation.

After looking into the exam homepage you will figure out that the only official book is the “Exam Ref 70-483: Programming in C#” by Microsoft Press. Somehow, I managed to find the first edition as a PDF file in GitHub and I decided to stick with it. The PDF reading was enough for me. There is a newer edition of the book but the changes seem to be really cosmetic and minor. Since the exam is really an old one, there was an update document on the exam homepage which is containing information what has been changed. I assume that the second edition of the book is reflecting the new exam requirements.

The second thing I did was to buy the Microsoft Official Practice Test which can be added to your purchase when you reserve a seat for the exam. The test includes 154 questions and it is a very close simulation to the real exam. In my opinion, many of the questions in this test are with higher-complexity from the ones on the real exam. Anyway, I carefully trained all the questions and used the official book (the PDF I found) as a reference point to find answers and explanations. The official book has also questions which can be used for additional training. Every objective chapter has 3 questions. All in all, I have made more than 200 exam questions.

This is not all. There is another book (not official) published by Wrox: MCSD Certification Toolkit (Exam 70-483): Programming in C#. I found it too late but it seems that it has additional free material which provides a lot of sample exam questions.

If you have followed until here and you have made all the preparation questions, you probably trained more than 300-350 individual test questions and this is a lot. On the exam, I got precisely 46 questions for 120 minutes and most of them were two-three times easier than the exam preparation questions. By the way, I took “at home” exam option and this saved a lot of time. Just make sure you read carefully what is allowed and not allow for this type of exams.

My conclusion is: seasoned C# developers with a couple of years of experience should take the exam immediately. You don’t need additional preparation nor advises. The absolute maximum for preparation for such an exam should be a weekend and nothing else. Everyone else – good luck. There is plenty of materials – the books, the official questions and plenty of MSDN documentation pages explaining the core concepts.

This is a blog post where I am describing my experience with releasing software. I am sure that you will find other more formal, more full-blown articles but the staff you will read here are based on my personal work background and reflect the reality at work (at least my reality).

Please be aware that this blog post is not discussing many aspects of the releases –  the delivery audience (e.g. internal, insider, stable), the release size (e.g. monolith delivery, microservice update, on-premises software), the release branches strategy, the release testing process and many, many other small details. It is solely discussing

the frequency of the delivered software.

Usually, every software you will write for the enterprise, your employer, your customer will be released sooner or later in one or the other form, somehow. My definition for released software is “software which is now used from the end-user and now is doing the real work”. Everything that is made as an internal release, test release, sprint preview release etc. is not a real release.

I.

The first model of releasing is “reactive release”. Basically, you wait until someone requests the software, e.g. a manager is nagging on you, a customer sends a reminder for something to be delivered, support is writing about some important bug. In these situations, the development almost has no control over the process and everything is based on the circumstances, usually made in the last possible moment. And “yes”, I worked in such an environment… Looking back, this sounds crazy. The majority of our releases were based on events. Very, very rare the product was just ready for release. My explanation for all this is the bad development process we had combined with the weak management and lack of development resources.

Pros:

• N/A. I don’t find anything good here.

Cons:

• Development can’t plan anything
• Most of the time is spent in fighting fires
• The developers look “unprepared” in the eyes of the business

---

II.

The next model is a “high-frequent release”. We were doing a release every second day i.e. every Tuesday and Thursday, sometimes even more often. There were no exceptions, no excuses and the only allowed holiday from this busy schedule was the time around New Year when most of the stuff is any way out of office. I think this approach teaches the discipline to have always shippable software but also creates an awkward situation where you can’t do big changes due to the short release cycles. The usual workaround that we were using was –  the “feature toggles”. With the help of some guard variables (the feature toggles), we were able to secure the new code to live in production before it was really ready to work properly. All this was awesome, but as I said sometimes was hard to solve complex problems while running in a high-pace. This release cycle model is suitable for online services under high-load where changes from a couple of weeks can be uncrackable in case some weird performance issues.

Pros:

• The development learns to be ready with shippable software at any time
• Small incremental changes can be monitored easily in case of problems
• Allows changing everything overnight

Cons:

• Hard to deliver big features at the same time with the frequent releases
• It can be distracting and less efficient
• Sometimes requires huge coordination efforts between the developers who are submitting changes

---

III.

The “low-frequent release” is the opposite of “high-frequent release”. In my case, we were shipping the software twice per yer aka as GA (general availability) release. In many cases, this looks like the following: you are developing 3-4 months and then the last 2 months you are fixing bugs, stabilizing the software, doing the optimizations and so on. I don’t like this approach because I like a much more dynamic environment with frequent feedback. This is simply not my style of work. I am more a person based on collaboration and frequent feedback. However, I see how some people will like this release type.

Pros:

• Complex features can be developed without additional pressure
• There are no excuses that something cannot be delivered (this is a very optimistic statement, I will say 🙂 )
• A lot of “manual” testing assures that everything works. There is a budget for that.

Cons:

• Generally a very slow process
• A slow or missing feedback loop
• Long living branches which should be supported for years. E.g. GA2018.1 will be actual for someone for several years
• Somehow the story “repeats” every  year over and over

---

IV.

And the last from my experience is “release multiple times per sprint, aka when a story is ready”. This means that there are no formal deadlines but when we are ready with something like a “feature” we will ship it without to wait on something else. Someone can confuse this with “reactive release” but they are not the same. In this model, the developers have control over everything because the foundation of the work is the Scrum sprint. We use bi-weekly sprints and we try to scope a delivery in the boundary of the sprint. To be honest, sometimes this is almost impossible. Stuff planed for 1 sprint a prolonged in 2 and etc. However, sprint dynamics is something I like. If the team is following the Scrum framework tightly, the infrequent progress sooner or later will become more predictable which means also more predictable releases.

Pros:

• Easy to adapt. You can do a frequent release after a short story or you can “wait a few weeks” after something big is finished
• High satisfaction in the development team, because you release when you are don
• Business and development collaborate on the right pace

Cons:

• Infrequent
• Sometimes releasing “whole” features can be dangerous
• Requires implementing Scrum process (maybe, you don’t have it your organization…)
  

  ---

Conclusion

I hope that you found the best release process for you. In my case, I am for something between II. and IV. – “high-frequent release” and “release multiple times per sprint, aka when a story is ready”. Both reflect my understandings and values as a software developer and I thoroughly believe that the truth is in the middle, between both models.

Have you thought what is the main purpose of your life as a developer on a paycheck? Well, I am in a situation where I have to answer myself this question – “What should a developer do?” and also try to influence my colleagues with my opinion.

Basically, I see it like this:

A) The developers should refactor the code, improve the product and do housekeeping all the time – including writing unit tests, documentation etc.

B) The developers should play with new technologies and try to use them at work when it is possible

C) The developers should do the sprint stories and do progress only on them

Many folks fail down in the trap to do A) and B) but it seems to be that we are paid to do C).

Is it possible to be only C) all the time? What is the right balance? How should we do any work from category A) and B) when the most value for the business is coming from the work categorized as C)?

The answer is not straight… but also it is not an excuse to choose often A) and B) in my opinion.

 

 

Recently I permanently moved to Aalborg where my family was already. One of the first things I did was to participate in a Meetup about Internet Of Things (IoT) – http://www.meetup.com/IoT-Denmark/events/229687332/ .

I was one of the presenters and I introduced the audience to Amazon Web Services’ solution for Internet Of Things. I enjoyed it  a lot.

Basically, I became very interested in IoT topic just recently. I think this is a field where the technical entry level is relatively low, it has huge social impact and it is fun to work with. Based on these thoughts I think this will be not my last experience with the topic of IoT. Some year ago I bought myself the Arduino starter kit. Now it is the time to further explore it 🙂

I am running a Synology NAS server for the last few years at home. Everything was OK all the time but recently the worst happened. The system became unresponsive, lost performance and it stopped to work in few days after a system update. Later on, I figured out that one of the NAS hard drives had to be replaced due to a huge number of bad sectors. In my opinion this was the real reason for the failure I encountered.

Of course, I had a backup but a small fraction of just newly available data was not in the backup set yet. Secondly, I have a lot media such as serials, movies etc. which are not backed up at all. My backup solution is CrashPlan and I was seeing endless days of data restore. The only alternative was a scanning and a repairing of the current disks. This was a hell. I had to buy a docking station from Inateck for my two hard disks. The docking station was attached to various laptops with “on the fly” Linux Ubuntu installation. I am saying “various” because the first one could not find the disks, the second one was having some video driver problems and the third one was just the right one. The RAID recovery instructions were just ridiculous but after few days of try / false attempts I was able to extract 100% of the data and save it to a Samsung USB external drive (which I just bought).

The above situation reconsidered my backup strategy. Scott Hanselman has a wonderful post about Synology setup and CrashPlan. In his blog you can find also few related articles which are the foundation of my research and opinion about backups. Right now, I am using the same Synology DS213+ with two new hard drives (WD), a tiny Gigabyte Mini Computer (GB-BXBT-2807) and the already mentioned Samsung M3 portable drive. I have one copy in the cloud via CrashPlan, one local copy via the Synology and one on a site copy via the portable hard drive. The mini computer is synchronzing the cloud and the local copy. So, that’s it my new backup!

In this post I will share my initial opinions about the Airbnb accommodation service. For those who don’t know what it is (I am really In doubt if someone has not heard about them) – it is a community of hosts and travelers who give and rent accommodation.

Recently I was visiting Switzerland and I decided to give it a try. More over I was traveling alone and this was a main reason to try it. You don’t want to have unexpected experiences when traveling with two small kids and a wife, right?

Site and app

The service has excellent site and mobile app. More or less it is looking as every other booking site. One significant difference is the instant chat you can have with host. I chatted a lot with my hosts, mainly about logistics and practicalities.

What did I try

I was in 3 different places – Geneva, Lousanne and Bern. Everywhere I was welcomed, got beddings, towels and wi-fi password. Really nice for a start. Despite of this everything else was different in terms of behavior and surrounding. I was having a virtual host, a French speaking host and a party animal which, indeed, was very welcoming host.

What do I think

During my trip I was thinking what kind of person will run such a “business”. I met three different paterns and I am still confused what this is about. I will say: it is a craziness which no hotel in the world can offer you. You get my more than you pay for. The experience, the touch to the culture, the personal attention are different and priceless. I am tired of boring clerks and stupid faces in every hotel I visit. So, definitely this is a solution and a system which will work for the near future.

Secondly, I was guessing if this is the real owner renting the space. I don’t have an answer or evidence yet, but sometimes it could be not. It could be something bigger, an agency or something similar. I think this is killing the experience and the idea. We should not allow it come over because the renting out gets commercialised and the it is loosing from its spirit.

Should I share my space

Definitely I will recommend and I will do it myself later this year. It is a tremendous way of getting new experience, some new fun and few bucks in the pocket. You can only win from all of these!

The last couple of weeks are crazy. I did a trip every week.

Milano, Cluj, Trondheim, Söderåsens and now Switzerland.

The list became large without actually to plan it.

Let me resemble  shortly what happened .

After a planned ahead visit of the derby match Inter – Milan, 19th April, I went back to Romania together with my family. We baptized our daughter there on 25th May.

On the next week I returned to Denmark, alone, without my partner and kids. I bought myself a last minute ticket to Trondheim where I spent three days.

The week after was occupied with a mini trip to one of the natural parks in southern Sweden – Söderåsens. I was there with a friend of mine, just by car and for a day.

And lastly I traveled to Switzerland where I spent 4 nights all together in Geneva, Lausanne and Bern. This trip was semi-planned as I booked all the accommodation in the same week.

Next week everything is over. I will wait at Malmö airport for Roxana and my kids to be back and practically the big travel period is done.

In conclusion I will say that this is a great experience where in different moments I have been with friends, family and alone on the road. Definitely it is refreshing, interesting and I am able to follow and concentrate on my daily jobs. Productivity wise was good, especially when I was alone on the road.

In some of the next post I will share more insight from the trips, especially about the Airbnb accommodation service and other interesting stuff.

This is my brand new blog. I will share everything interesting about me and my family.