4developers – thoughts after the conference - part 2 (discussion panel)

I planned to give you an overview on Azure Bots and GraphQL today, but, in the end, I covered discussion panel today. Please have a read as far as there are quite a few smart thoughts of ‘Bottega IT minds’ 🙂

4Developers discussion panel

The grand finale of the conference was the discussion panel with Bottega trainers. Not only engineers! We’ve had a chance to listen to Artur, Mariusz, Łukasz, Konrad and Tomasz. The whole session was conducted by Maciej.

I cannot recall all the Questions and Answers in the manner they’ve been articulated, but I noted some concepts. Hope you’ll find it helpful.

I won’t bore you with the additional introduction today, let’s see what the lecturers have to say about development – and not only!

What bothers Polish IT?

We have a problem that many of the programmers are arrogant, selfish and too confident about their abilities, skills, and position of ‘gods’ in society. There is also a lack of understanding (or even hate) for those who came into IT in an unconventional way. For those who are self-educated because they picked another direction during their studies and needed to learn programming by themselves. It is surely a bad trend, but it is a disease that hopefully can be healed with proper engagement.

Another thing is that programmers treat business guys like a necessary evil. This sick attitude causes a vast majority of troubles in communication in between them and customers during the project. We must remember that on the end of the day they are the ones who pay for our work. Treating them well and doing our best to understand their needs may be a fairly good idea then! In fact, they are our teammates!

And lastly – programmers need to build the mindset oriented on usage. Konrad said an anecdote about his friend programmer who worked for a bank and went to the department they created software for to do some consultancy. When he came back he said with amusement: “Guess what! They really use our product!”. It would be better, not only for end users – but also for ourselves, when we will develop our programs with having in mind that someone will use it some day. And he will expect this program will actually make his job easier.

At the end software is made for these purposes: to make money or to save money. It’s good to be aware of that.

How do you stay up-to-date with newest technologies?

The newest technologies/frameworks/buzzwords are not the most important thing in the IT world. What you need to care about are repeated patterns, understanding language mechanisms and looking at the topic from the perspective to see the big picture.

If you ask about how we supply trainings on such topics – we never deliver such lecture without comprehensive preparation. So there is no situation where ‘microservices’ reaches the market and we make training the other day. We must learn the topic, use it somewhere, experience some troubles during usage, solve them. Only then we can say – this may be a good start to think about producing good training regarding the topic.

Another thing is that each buzzword has a well-known cycle. Like Domain Driven Development had, SOA, REST, Microservices, Serverless etc.

It always looks like that:

Microservices are great! Check it out! Awesome! So modern! Wow!
OK, microservices are nice, but they don’t suit all cases/users/systems etc.
“How we implemented Microservices in our solution and why we failed”

Having that cycle in mind can save you some time. You will also be able to predict what will be the true buzz word of the following conference! 🙂

How do you convince the customer to pay for unit/manual/integration tests?

There is one thing to remember here: Quality is not something we trade. Thus we can’t agree to abandon testing. This is not a “cost” that we can decrease on demand to make project affordable. Testing is an integral part of professional programming and we cannot deny it. It is necessary. Would you like to drive the car whose breaks haven’t been tested?

If the customer keeps proposing you to omit this part of programming – you can tell him to write a program by himself, since he knows better ways of developing software.