Breaking Bad Software Development Habits

[@ChadEdge]

More, more, more (of the opinionated and story-driven tales): It's like you're speaking about my company directly :)

[@andyg8762]

I'll second that! Really enjoyed the video, and these are often helpful to help clarify discussions with the teams in context at work -- keep 'em coming. :)

[@glhrmcosta91]

The sad thing is that Dave seems to be talking about all of our companies. This only proves that these problems are way too common...

[@OggerFN]

I like the opinionated videos. You cannot always please everyone and there is nothing to discuss or learn if no one speaks their mind.

[@TheMeticulousMoo]

2:23 "possibly with fluffy birds singing and clouds in the background" LOL 🤣 Great video like usual!

[@perfectionbox]

if a dev is off for a day, it's faster to wait for him than to spend a week getting someone else up to speed on his code.

[@myobpro8516]

My notes: 2:05 Focus only on the happy path: It's your responsibility (and only yours) to identify faulty scenarios. 5:23 Code ownership: To prevent Bus factor (see en.wikipedia.org/wiki/Bus_factor). 8:12 Somebody Else's Problem: Stop complaining and start having a positive impact on your team and the end users. 10:21 Afraid to Change the Code: Work on Assumption That Code is a "Best Guess" and It may be Probably Wrong! + Learn Refactoring Techniques. 13:29 Focus on Tools Rather than Outcomes: Pick the right and efficient Tool for a Problem, but remember your goal is to solve the Problem. Thanks Dave for these useful tips.

[@Kaslor1000]

Regarding 10:26 (Afraid to Change the Code) - I think that the most fundamental principle in software engineering, from which all other best practices and principles can be derived is ETC: Easier To Change. Whatever design or implementation decision you make in a project, make sure it makes your code ETC :)

[@researchandbuild1751]

I spend about 40 percent of my day afraid to change the code..lol

[@bankashvids]

Keep the opinions flowing, my friend! I love the passion for great software.

[@ContinuousDelivery]

That's the plan!

[@moonfiend9259]

This is such a breath of fresh air for someone like me who's worked a lot in stuffy, corporate help desk environments. I'm not sure if I'll become a software developer or not, but your way of thinking makes so much sense and can apply to many other fields in IT.

[@ShadCollins]

Really enjoyed this. Most of this is the mindset of experienced programmers but it is a good reminder and well-articulated. I would like to see more videos like this.

[@chrisalexthomas]

20+ year software developer here: I think you should explain your preferences and opinions more. I think that people these days don't form solid opinions sometimes and allow for a "both sides" approach which means that nobody is happy. Sometimes it's better to choose plan A or B, as long as there is a plan. Doesn't matter if eventually you switch but as long as it's deterministic, reasonable, and reasoned. Especially when you have so much experience in other social aspects of coding due to the considerable amount of years you have working in this environment you have an invaluable insight into what sounds good on paper but what works better in practice. It's great to talk about theory, but it's often good to realise you work in reality and you have to weigh up what your options are and give advice that will come to a valuable result. I think you certainly have mountains of that experience and I enjoy listening to it either because sometimes it reinforces what I also think, other times it gives me a side of things I didn't yet experience and I can learn from, but there wasn't yet anything you said in any video I watched where I actually whole-heartedly disagree with you. Sometimes I've shrugged my shoulders because in my practical experience it didn't work like that. But I also have enough experience to know that what I experienced might be very different than you did. Keep it up!

[@miletacekovic]

The moment I saw the title for this week's video, my first thought was 'Ah, this one will sure be boring and will not keep up to the very high standard of this channel, there will be usual stuff: don't write this code, don't do that...'. But Dave managed to make me wrong, the 'dont's' in this video are really the fundamental ones, and are more representing bad ways of thinking than usual software development bad habits you would first think of.

[@ContinuousDelivery]

Thank you 😁😎

[@Metruzanca]

You mentioned eclipse vs intellij. Can we all just agree that IDE agnostic workflows are the best? I've had many times that something would only work in eclipse and man was that frustrating. IMO, your build tools should work from the command line and your editor/IDE should meerly integrate with those existing command line tools. Essentially making your IDE/editors an alternative interface to a CLI.

[@TimSchraepen]

Adding opinions is what makes these video’s more informative I would say, but only because when expressing your opinion you still leave room for other opinions (there are no dogmatic statements). As usual, this was a great, comprehensible video and I give thanks for your contributions to the software community. 🙏

[@jhonhernandez9210]

Mistake: Focus only on the happy path Users won´t do what you expect Think and dessig defensively Always think: What if Think through the risks, even if you decide to defer dealing with them Watch someone use your software Break code ownership with pair programming Mistake: It is somebody else´s problem Mistake: You are afraid to change the code… and to break something That code is a best guess The code is probably wrong Manitain the freedom to change the code Good tests describe what the system should do, not how it does it Use approbal tests if you have nothing in place yet Mistake: A focus on tools rather than outcomes Tools are not the point of what are we doing Focus on the problem before the tools

[@POINTS2]

The point about the tools is spot on. Good developers can get setup themselves with what they feel comfortable with and get the job done.

[@FlaviusAspra]

Beware though, many developers won't know how to do basic things with their preferred tool when you ask them. Examples: mounting remote file system, find usages of a method, etc. "Use whatever you want" must be accompanied with "if you really and truly master it, otherwise use THIS, because with THIS one the team can help you become a professional".

[@stephenbutler3929]

@@FlaviusAspra It's an interesting thing with such things. If there's a reasonably strong preference within the team then I think it's fair to say "We'd suggest you use this because if you do we can help you. You can make another choice if you think that will work better for you but if you run into problems then the likelihood is that you'll be on your own..."

[@FlaviusAspra]

@@stephenbutler3929 noone is ever on their own in a team. Whatever one member does not manage to do, because they don't know how or it's not possible to do it because they chose a poor tool, then others have to do more work. Just because of ego? Team decisions should be democratic, BUT technically grounded.

[@ThePC007]

​@@FlaviusAspra "Beware though, many developers won't know how to do basic things with their preferred tool when you ask them." Maybe, but if they need to do whatever they need to do they are just one Google search away from finding that out. "if you really and truly master it, otherwise use THIS, because with THIS one the team can help you become a professional" *EDIT:* KZbin removed my last paragraph, but I explained here that you can have the same project open in multiple tools at the same time, so you can have the best of both worlds.

[@FlaviusAspra]

@@ThePC007 if you go through some personas, you'd see how those you mention are an overwhelming minority. Google or not Google is not the key point. It's more like: whether they've used any IDE for that particular scenario. But people who have used any IDE in a wide range of scenarios are very likely to have tested a bunch of them and settled for what they master already. Googling for something you've done in the past does not count as research when facing unknowns. It counts as "recollection of your own notes from when you've done it last time"

[@kiseitai2]

I agree with all you have said! The main issue I have encountered is with the field I make a change in. I feel that in medicine (US), you often aren’t allowed to voice these concerns. Requests are usually voiced as “can you do this “ rather than “we would like x.” Even people I have worked with admit that the way they push for requests is what lead to the current “bad” code. Yet they immediately push for more of the same. Since the person representing the hospital is from the perspective of the developer the same as the hospital, you feel pressured to comply even if they are wrong because they write your check. As both a physician and software developer, I have felt awful and incapable of expressing my unique professional expertise when interfacing with physicians. They want to control the final product but they often don’t want to defer the implementation details to the expert. It is really bizarre given that medicine is in part about relying on your colleague experts to take care of your patients in areas you cannot. Things easily become about how to make the person in the meeting happy instead of how can we together make something that ultimately makes a difference for the patient. I agree with your suggestions but I have found it unnecessarily difficult to apply the good advice.

[@JaumeSabater]

Back in the day, like very much back in the day, I did code a few CGI programs (those that went in the cgi-bin/ directory in Apache, if you were there at the time) in C (before Perl and PHP). It did take longer, but I was profficient in the C language, programs were simpler and they were very, very fast (at a time in which computing power was definitely not what it is now). Nonetheless, lovely video, as usual, and lovely t-shirt ;-)

[@CTimmerman]

How good were they at handling oversized emoji input?

[@JaumeSabater]

@@CTimmerman Very efficient as well. You know, /dev/null was widely used among we UNIX geeks, if you know what I mean 😏

[@DevinWeaver]

Please, more opinions and well explained best practices. I’m in the beginning stages of my senior level career and I’m desperately trying to develop the skills to prove my points and understandings the way you do in your videos. There are reasons I do things the way I do and much literature agrees but I find many don’t study the same things and disregard the conclusions I come to in favor of “just getting it done” or many other false ideas you’ve covered before. I love having these Senior Developer styled videos to help round out my own journey Thank you..

[@ContinuousDelivery]

Thanks for the feedback. Glad you find my videos useful!

[@i41-x7e]

Moar opinions! And I have to add about the fear of changing code: there is an eagerness to do so that can be just as dangerous. One of our juniors constantly wants to rewrite everything. incidentally I'm surprised "If it ain't broke don't fix it" didn't make the list.

[@sanderdejong66]

“The bus test”. For some reason, in The Netherlands, this is called “The tram test”.

[@CTimmerman]

I've only heard it being called "Batman & Robin". Guess that's the rockstar name.

[@aldosilva6]

"Some guitarists like gibson, others like fender, but it's the music that matters" it was the best part for me. And also the code ownership, I've seen a lot on my daily work.

[@a314]

Fantastic video. To inject my opinion in this already opinionated view, the goal of software engineering is not only to solve the problem, but doing so with the least possible complexity. Minimizing complexity is more often ignored or forgotten and becomes technical debt. Repeated instances of this results in dysfunctional organization.

[@einschnehk9756]

You're a very experienced software engineer. I think nearly all of your regular viewers value your perspective and opinion on things more than anything that you could talk about instead. It keeps conversations going and isn't just a read out wiki article. Please do speak about everything that floats in your head and what you think about topics that you personally care about in your field. I think the rest will come naturally. :-) I personally love how you bring over arguments and even if I'm not having the same views it always lets me retrospect about my personal experiences leading to my view on things and reflect on why I have them and how I can learn to shape them in a way that I feel best in doing what I'm doing in my environment. Thanks alot again for this enriching channel of yours.

[@ContinuousDelivery]

Thank you! 🙂

[@joegoloso]

Great video Dave! I definitely want more of these.

[@MoreBassieIsMoreFun]

the opinions are great to hear. Reminds me of something Philip Defranco once explained, about first giving the facts so the viewer can form their own opinion, and only then giving yours as food-for-thought

[@ContinuousDelivery]

Yes, I hadn't thought of it like that, but that is my approach.

[@adamdubnytskyy7469]

Brilliant thoughts about modern software development practices. Thank you!

[@JustLikeBuildingThings]

Thanks for this, comments on happy path hit home hard. I'm noticing a trend (albeit contextual to where I am) where "Agile" has become the buzzword and it apparently means deliver fast and forego good engineering to some. What's happening is a full shift right of analysis/discussion which is where unhappy paths and edge cases are born - naturally these begin coming out in production / test or in sprint to solve - yet they're so easy to see up front with a bit of collaboration. The only factor they miss, once pushed right the time element is squashed, so worse decisions are made - ad-hoc fixes / quick fixes / "we'll fix it properly in tech debt" (that never gets done).

[@roaba3581]

As always, very insightful. I would really like a video about how to sell management and / or my own team on adopting test driven development. My team is still a little on the fence about it, but I'm pretty much ready to leave the company, if nobody wants to put in the effort. So far my own tries to explain the benefits have been received with skepticism and disbelieve, that it wont just slow down development.

[@vilivilhunen3383]

Strong opinions of course. Our job is to balance between opinions and find the best average. Have to check out your book soon, my software project is launching off

[@YonoZekenZoid]

I just stumbled on your videos today and I'd like to say they're absolutely great! thanks youtube algorithm for recommending them!

[@RU-qv3jl]

As someone who is pretty new to coding and learning, personally I like learning from people who are willing to share their experience. I like to listen to your opinions, so long as you avoid allegiance to individual ideas without explanation. Best of all if you would also be willing to take the time to engage with people in comments who may have different ideas. I have only come across your channel somewhat recently and don’t comment much yet so I don’t know if you do that or not. Either way I love your content and want to thank you for sharing your thoughts, ideas and knowledge.

[@ContinuousDelivery]

Thanks for the thanks. I try to respond thoughtfully here, and on my Twitter account. I do have limited bandwidth, and so can't engage with every conversation, but I try to answer questions as much as I can.

[@rdwells]

In 15 minutes, you managed to summarize every rookie mistake I made in my first job. I wish I could honestly say that I never made them since. Also: keep it coming with the opinion pieces. I already know MY opinions; I want to hear from others who may change my mind.

[@alrunner4]

I appreciate hearing that we should expect to change code; I've long been skeptical of the Open-Closed principle on these grounds. Many times OCP seems to be taken to justify layers upon layers not for clarity of architecture, but in order to avoid modifying any preexisting code on principle.

[@ssssssstssssssss]

Being opinionated invites debate. Good debate is valuable. You could even read the comments and make a video with counter opinions if you find some good ones.

[@cloojure]

Definitely like the opinions on what is important & what works/doesn't work.

[@tidus4400]

I love this format!

[@EricKolotyluk]

I completely agree that it's a mistake to only focus on the happy path. It seems increasingly common in products and product design where no only do people not verify product behavior/function adequately, but they don't even validate design properly. Part of the problem I feel is with Agile practices, where I have never seen any organization that ever practiced real agile, and two week sprints are the invention of the devil because it forces people to focus on velocity rather than quality, to throw stuff over the fence before its ready in order to win their velocity brownie points. Also, people love to use the phrase MVP or Minimally Viable Product, but they never seem to want to move past that to Well Engineered Product,

[@ThisAintMyGithub]

I think your opinionated episodes are honestly great. Your point of view is very interesting and honestly I feel like it's the right way to approach these kinds of problems. Thank you as always!

[@ContinuousDelivery]

Glad you like them!

[@stephenbutler3929]

Remember Murphy's Laws: 1 - If it can go wrong, it will go wrong. 2 - If it can't go wrong, it will go wrong. 3 - Just as you think things can't possibly get any worse - they will.

[@revietech5052]

The worst software development habit is writing code functions the size of the Hoover dam

[@ShadCollins]

hahah. Yes....

[@MrAbrazildo]

Agreed. But I found a crazy guy who thinks otherwise: kzbin.info/www/bejne/amWWhoGbfNd5pa8

[@metalalive2006]

I like the similar topics , I am preparing interviews and it may be good resource of reverse interview question for developers

[@adhamabohasson]

I like to watch your videos for the opinion you have about the subject. And I think most of the time even when you are really pushing for one side you are stating the other argument. That’s more and better than most of people do. Thanks for the valuable info

[@DoNotTouchJustLook1]

Love all of your videos. Amazing content and the length of the videos is perfect. Keep it up!

[@ContinuousDelivery]

Thanks for the positive feedback!

[@MattPayneOrg]

It's usually easy to get going inside of a spring boot, angular, or rails code base.

[@Arvigeus]

Your opinions come from experience, so it is good to have them.

[@abrorabyyu6221]

focus only on the happy path me: ah okay, this is not just my habit. but my entire life is mistake

[@RealCaptainAwesome]

What do we do about the contaminated data?

[@Countryen]

More. Thanks for the tips/advices.

[@MrAstrals]

All we say is an opinion unless mathematical proof is provided. Which makes human conversations possible, exchange of opinions. Opinions make other humans interesting, open new horizons, spark new ideas. This is my humble opinion on opinions.

[@bleki_one]

I don't believe someone can even be a software engineer if they are afraid to change the code, because they can break it. It is not a problem when you break something, the problem is if you won't learn anything from it.

[@Zoltag00]

The more I hear of your opinions, the more I find myself not only agreeing, but often-times of the same (or very similar opinion). You frequently express ideas very coherently that I struggle to put words to, so have found your videos an invaluable source to pass onto the boss, to make my arguments for me :-)

[@fogboundturtle]

Design for resiliency. Absolutely and this is why Agile is failing as business stakeholder believe that value has to be delivered in every 2 weeks sprint. You can only do happy path within that given time. So developer/product owner focus on their velocity so they look good for leadership. They will only review and fix their happy path when it breaks.

[@alkalomadtan]

About the code ownership: it's true, that shared code is a stronger model, but each piece of code being it large or small, needs to have the right, complicated model in its developers' mind to do useful work on that. Since people's mind is limited, so the potential of doing the right thing for an unknown code is also limited. There are toxic misunderstanding of shared code's superiority in many big organizations that require the developers to learn/maintain much wider parts of complex systems than a human mind is really capable of. So, shared code is good, but don't forget the humanlimits and the overhead of model handling in people's mind.

[@abduljabbarazam943]

Great video again. Is their an ETA for the Modern Software Engineering Book?

[@ContinuousDelivery]

Thanks! The book is in its final stages of editing and is due to be available at the start of December. I will announce details on this (and other) channel.

[@romeli1941]

I like this very much. Please keep them coming. Thanks.

[@BlackBob99]

I once got turned down for a contract because I did not have enough experience with the latest version of the tool set they were using. even though I had years of experience in the problem domain. Needless to say that the project was a failure. This is the thinking that the solution is in the tools, not the people using the tools.

[@ExTex23]

I love these opinionated videos, as long as you keep explaining why you have these opinions with solid arguments.

[@cakep4271]

A software developer buys a bar and is testing the competence of his bartender by pretending to be a customer. "I'll have 1 beer....100 beers... infinity beers...0 beers...negative infinity beers.." in every situation the bartender responds to the situation perfectly. "Awesome" thinks the software developer. "This bar is ready to handle anything!". Then the first real customer walks in and asks "excuse me, where is the bathroom?". The bar explodes.

[@arunNaparna]

Great points keep them coming

[@1995taunus]

Thank you for your helpful video

[@edhodapp6465]

It is sad how many places actively work against every single part of this and other aspects of efficiently creating code. It is by far the rule and not the exception.

[@fnizzelwhoop]

Hah -- I have been asked/ordered to put a bug back into code, because the board hadn't reviewed the issue .. because, well there was no issue in the issue tracker for the bug (I just happened to stumble on it while working on something else, and figured I'd fix it since the the fix was trivial and obvious). At the time I was stunned by the absurdity of it. While I'm not going to go so far as agreeing with such rigid systems today, I will say that having done more work with high-assurance systems over the years I understand how these weird rules can come about.

[@vitiok78]

I almost always feel bad and ashamed watching your videos... But I can't stop because it's great to understand what I'm doing wrong!

[@ContinuousDelivery]

😂

[@AbrarAhmad-mz8vl]

I love thumbnails.

[@TifTif86]

great watch. Bonus points of the shirt.

[@kevinfleischer2049]

I liked this episode very much. So yes, keep it that way. Some more stories are appreciated 🙂

[@MrAbrazildo]

11:18, too many hacks lead to this.

[@PaulSebastianM]

We all need to download this video and keep it in our pockets at all times! 😊

[@ContinuousDelivery]

Please do! 😂

[@Vaelenthior]

I thought you were going in a different direction with the problem of code ownership. My bad habit tends to be that I will refuse to take ownership of parts of the codebase that I feel are poorly written and effectively treat them like a black box. The end result is the same however, with certain parts only being worked on by certain people.

[@oldcountryman2795]

You can have that freedom when you’re a minor player. If you’re ever in charge of a project you will have to take responsibility for all of it. Even the parts written by imbeciles. Then you’ll be looking for the guy that isn’t afraid of taking over anyone’s code to make your number two.

[@danm6189]

Gotta talk about it, help other people improve, otherwise you'll be two steps forward one back from here on in, IMHO... If there's others with a bit more patience to work with the culprits maybe you can combine efforts? All the best.

[@liquidpebbles]

I enjoy hearing the opinion of a well seasoned master of his craft

[@Oswee]

Hi. Just captured the thought that you could add few words what your sponsors does. These days, there is too much topics to "click on the every link posted below video"... so i just skipping that. But if i would have an idea what stands behind those shiny logo's mby there would be something interesting for me. About the tests... just an personal opinion... Many developers just hear the constant buzz around... "tessstsss, tesssstsss, tessstsss... more tesssts", but still do not understand the importance of them... they see it as time waste... they try to unnaturally enforce testing just because that constant buzz. And one of the reasons could be, is that i haven't seen any single "it clicked to me!" article or video which explains the PRACTICAL importance/benefits of testing and kinds of testing at different stages/types of software. Like... at ELI5 level. Rarely who keeps in mind non-english native auditory as well. Etc. Testing for me personally clicked when i saw comfortable (good DX) tooling to do it and when i thought about: "Ok, i use this library X... which does Y... How comfortable i am to upgrade that library? Does [if it compiles then it's fine] is enough for me? What if the runtime output of Y changes? What if i want to move stuff around?" So for me testing started to "click" only at this stage of my evolution. If the DX is awful... people will naturally try to avoid it or to make fake code coverage. Just an opinion. As always... great content. Really enjoying! P.S. I would like to hear about licensing. How to track, licenses of dependencies, their dependencies, etc, etc.... About CLA's, and all that related licensing stuff. It's pretty complex topic, but IMO not that much covered.

[@d347hm4n]

Opinions are good as long as they are backed with experience. You clearly are very experienced so your opinions are very welcome.

[@CTimmerman]

If ten former employees broke the code, it's reasonable to expect the next one to do the same, but at least listen to their explanation. I think the 3 different refactoring opinions in the supposedly senior team members played a big part.

[@aharonha]

The bus test is one of the worst to think of, yet important measure of a team.

[@ShadCollins]

This is an important test in a company period. I deal with business continuity and one of the things everyone is afraid of talking about is what happens if X person gets hit by a bus? Now how will the company function? This isn't restricted to just development.

[@aharonha]

@@ShadCollins Just thinking about it makes me shiver

[@danm6189]

Management solution: carry on, issue hi-vis vests.

[@13b78rug5h]

Agreed with most if not everything. Make these type of videos in future as well.

[@MultiMinors]

Answer to question from end: MORE

[@ArchiDimon]

I aim to misbehave. So, I won't give you a like after already leaving one in the first place seeing that amazing t-shirt of yours!

[@FlumpStudiosUK]

Great vid and spot on!

[@michaelnurse9089]

More please.

[@jamstawildman]

Just to add to what seems to be the most common response: more, more more! :)

[@jadeflon]

Inspiring always

[@tj71520]

I could have used your knowledge 14 years ago, then I might still have had a chance to get a job in IT now.

[@christianm4906]

Opinions are more than welcome

[@Pedritox0953]

The happy path a nice concept

[@talk2s5061X]

Love it more please 🙌🏾

[@arawndavies8525]

WE NEED TO CODE JESSE

[@EricZiko]

You kind of look like Morrissey's older brother 😜 I love your channel and keep up the good work

[@presbiteroo]

I need the same t-shirt!!!

[@AlexAegisOfficial]

"...me neither" I felt that

[@THEMithrandir09]

If you started a small company today, say with a dozen developers, what practices would you employ to efficiently write good software?

[@CTimmerman]

I've only had a team with a dozen devs in a company with $7 billion in sales, 1,146 branches and 19,700 employees in 32 countries across four continents. They could do more with less but insisted on doing things the hard way.

[@karlwaugh30]

More opinions are good. I think some form of examples or demonstrations could help to clarify some of the ideas, even if they're just toy examples at the end of the day.

[@j.j.9538]

Everything that you speak is true, but most companies won't provide the enviroment in which these good practices can be maintaned. Developers can do their part, but mostly, the company has the last say.

[@MrAbrazildo]

Whenever I decide to pass something bad, I use to take note from that, usually in pejorative words, to incite fixing.

[@j.j.9538]

@@MrAbrazildo Yeah. me too, but with tight schedules, i rarely get the chance to go back and fix it. I think it's a problem without solution. If a big company decides to account the time for refactoring, its prices won't be competitive. The only companies that have the highest chances of ridding itself of bad code are some long-term oriented startups.

[@lhlee888]

I work at one of GAFA and so far most of the bad habits are very discouraged

[@MrAbrazildo]

@@j.j.9538 According to what I've been seeing in presentations, companies wait until a disaster happens (due to bad coding habits), in order to take an entire different posture.

[@1oglop1]

@@MrAbrazildo The maybe "help" disaster to come sooner?

[@jensBendig]

If there‘s a part you‘re afraid to change: There‘s the problem. Change it.

[@John-pn4rt]

Another bad habit is as a leader thinking you know it all and that it has to be done your way - rather like my current boss!

[@ContinuousDelivery]

Yes, a common problem for technical leaders. I wonder if you've seen my video on this? kzbin.info/www/bejne/oH7TdHlmj5tladU

[@SohailSiadat]

The problem is, unit tests may impose a bad old design and make it difficult to change

[@ContinuousDelivery]

Clearly I think you are wrong, here are some of my arguments for why: kzbin.info/www/bejne/op-XiKGujZKqqNk

[@togelian]

I like to get your view on things. I might not agree, but that's just being human and a thinking being :) There is very little I can do about the culture at my workplace though, even if I see your point.

[@karthikeyanak9460]

Nice one

[@fiatalembertarsravagyo249]

sound quality could be better, for some reason it is barely understandable

[@tuberklz]

distilled wisdom

[@akab211]

I allways expect the worst. It comes naturally to me.

[@Hirnlappen]

More opinion pieces please

[@Hirnlappen]

(Not that I don't like your usual content)