There is a heavy price to pay for honesty.
This site has always been a description of the reality that people in IT experience, so I'd like to look at my experience working on development teams. The following are general experiences I have had across companies. No experience is associated with one particular company and does not necessarily serve as a criticism.
Got lots of ideas? Do you want to innovate? Do you enjoy finding elegant solutions to the complex problems your team is solving that are plaguing half the company? Do you realize the importance of security, software design, and finding project bottlenecks?
You'll probably be unhappy on the development team for a long time.
Teamwork is something I've been struggling with a lot lately - I mean, I'm specifically swimming in it and trying to understand the completely unintuitive principles for me to adhere to.
People like me are a potential source of problems and conflict. It's cool to think of it that way.
Every company has its codestyle rules. Unfortunately. It annoyed me so much at first.
In this regard, I have long been looking for a procedural solution to code review. I have been playing with PhpStan for a long time and following the ideas around it. The basic idea behind PhpStan is that it only highlights objective errors that are certain to occur at some point. The more I explore PhpStan and take it to the next level, the more I internally validate how true it is.
It would be nice if PhpStan would be implemented in at least half of Czech companies. It would be even better if at least to level 6. In practice, I have experienced that the best companies have level 4 or 5.
Just the other day I was wondering if there can be a real running production application that has its own development team, and it doesn't even pass level 0 - that's the level that controls the things you would expect in any application. Something along the lines of making sure all classes and functions exist, files don't have parse errors, and so on. And yes, there are such applications. But the situation is improving in the long run. Hopefully.
So I follow a similar approach with codereview. I only report things that are objectively always wrong. I often run into misjudgment of degree - something is wrong, but again, it's not such a big problem that it needs to be addressed. Many problems are solved by convention, or by declaring that the risk is small, so there's no point in treating it.
I've always considered missing data types (even compound ones) to be a critical bug. Then I understood that there is test and dump.
I don't think I have a concrete conclusion to this part. I just have a lot of subjective comments about it, which are more likely to be a source of mutual misunderstanding, so I won't post them. Long term, I'm inclined to the conclusion that I can't do codereview - either I'm too strict or too benevolent. I can't tell at a general level what really matters and what isn't so important. I'd be quite interested to know how other people do it. No one has yet been able to give me an answer that I can use, too.
Do you have an agency and do custom web development? If you're not big enough and doing big projects for other corporations, you probably won't exist one day.
The reason this happens is because of poor funding for custom projects. It probably has to do with the nature of the contracts, which are more profitable for the buyers. In fact, most agencies are brutally underfunded and only make a real profit for the owners.
When you internally develop a project as a company for yourself, a delay in delivery by a month probably doesn't matter that much. As an agency, if you don't deliver a job by a month, you're guaranteed to be slow asleep at work that said month, consistently ruining your health, the client swearing into the phone and tickets, always asking if it could be faster, and as a reward you'll still pay a contractual penalty. And if you don't, the client will label you as an unreliable contractor and may consider going elsewhere, where it won't be any better anyway.
But those are the rules of the game, which I've come to know in practice, and which have put a hole in my budget.
Contracting is probably the most complex form of business in IT. You don't want to do contracting. Contracting will destroy you. They'll call you on the weekend, at night, at Christmas. Half the work you do, you don't get paid. You'll be apologizing for mistakes you can't make. You'll be looking on Instagram at the storytelling of friends who went on their third vacation this year while you sit in your office at 3am on a Saturday finishing up a client project that you'll get scolded for on Monday anyway because there was more in the contract than you could get done. People will take vacation and sick days and you'll work in their place. Or you get terminated. And then you'll be happy to pay the rent.
But then again, you learn a lot. Because just under pressure, you have a lot of pressure to learn and be efficient so that next time you can get a little bit more done in the same amount of time. The bad thing is that you can't really apply that knowledge and experience elsewhere because companies just aren't interested (I explained above).
Fortunately, this is a 2019 story and it's a long way off.
If I'm doing what I enjoy? Do you? :D
I guess it's all a matter of proportion. You will probably never do a job that is 100% fulfilling. You'll probably always have someone explaining to you that you can't do the thing that you've been forcefully learning for 10 years and you know internally that you can.
On the other hand, for a certain amount of denial of your own personality, you gain the space to have something more. Like weekend time, better health, more time for yourself, a stable environment, etc. That it can't be sustained in the long run is obvious too.
I like being able to try different things to experience first hand how others have it. Working on a development team is a huge bore compared to a custom job.
It's no longer about finding the best and fastest solution, it's about collaboration. It's about improving communication, emotions, and most importantly, learning to be human. And that's a huge value, too.
Jan Barášek Více o autorovi
Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.
Rád vám pomůžu: