@cafecortado No, in certain companies it all depends on who is presenting the idea.

After any such meeting, I write the agreement down. Either as a comment in the ticket "as discussed in today's meeting and agreed by @PERSON and @OTHER_PERSON, the UI implementation will not be responsive" or I'll drop the respective stakeholder a mail simply stating the summary.

Never, ever will I rely on verbal agreement.

Why? That's why!

So that I can point to them: You yourself made that specific decision that informed my implementation. And if you want to change it, while that's your prerogative, we both know that the entire thing will take longer to finish.

Good companies will even make an effort to create a protocol on these kind of meetings where the important agreements are written down.

The problem is: A function can have error states. You always need a way to communicate the error. Union types are one way, so are exceptions, or the error type of go.

Not all of those are equal, yet you'd be surprised how many developers hate using exceptions.

The async rule keyword makes no sense to me.

Marking a function async is nothing more than syntactic sugar for: this function will always return a promise. Nothing more nothing less.

async fn() => 3

You'll know you get a promise (even though it instantly resolves).

Furthermore, the async declaration allows the `await` keyword. Yet you don't have to use await if you don't need it.

While it is true to use `await` with caution and only when you need it, there still is a benefit of ease of use of declaring all functions that may interact with Promises or return them as async.

If you don't mark you function as async and still work with promises you might get stuck in callback hell and being unsure what exactly your function may return, and I worked with libraries that sometimes returned a discrete value, and other times some promise. That's madness.

Any kind of version control system is really, really complex. Due to the decentralized design of git, it has a bunch more layers of complexity when compared to the old school version control systems like Subversion.

It takes time to get to know git, I only felt comfortable after 6 months of using it, I feel confident after years, yet still it boggles my mind from time to time. (WTF you mean the meaning of theirs and ours is switched during a rebase!?) Biggest compliment was becoming the go-to guy for every git problem in one company.

As developers, we need to work with loads of technologies. You can't be a master of all. You don't need to be the git guru within your team, others will fill the role, and most of them will help you to learn it.

Git error messages are some of the most helpful ones I've ever seen. And its documentation is vast. There are also some online playground offering deep dives in how it works if you're interested learning more.

Also in regards to "we need this to be more generalized", my go to remark is: Do we really need that? What other cases are we likely to have to implement next?

There's rarely nothing worse than premature abstraction, as either: you ain't gonna need it, or if abstracted without any use case in mind, the choices you did then will come to haunt you once the real world use case comes along and completely destroys your design.

Sometimes, a solution can be very concrete and is better for it.

I recommend making a habit to backbrief once your told to do something. It may appear weird and redundant, but I caught a lot of miscommunication right then and there before writing even one line of code.

Very contrived example:

Boss: implement the red button.
You: ok, let me backbrief to check I got it right: you want me on that project x to implement the button that does y and it should be red
Boss: no, I'm talking about project Z

Let them know you are doing a backbrief. I had people think I was dumb for repeating what they just said in different words. Especially if they are not aware of the concept.

Still a bit confused. Is she coder? Is she a manager? Is she a supervisor who codes?

Basically, if there's power dynamics involved it's always hard to communicate on equal footings. The higher basically can force their vision, no matter the merit. It's bad leadership but I've experienced couple of times.

I also can relate to such people always being in meetings not taking their time to properly explain themselves or use words that are clear to them but not others. (I remember discussing domain driven development hours on end and I swear everybody had a different understanding in the end but the entire team pretended to have a consensus just to get out if the meeting.)

Confusion and getting lost in communication is normal. It's okay to be confused. You did the necessary part already by telling her you don't understand what she means. She has to explain it now to you..

@Nmeri17 You may call for assistance. The called upon may flatly refuse you. Why is this such a hard concept for you? They also are not required to promise you a feature that you need. The sooner you really understand that, the less frustrated you'll be in the future.

What you call "division of labor" I would call coercing people to work, free of charge, in a direction you want under the open source umbrella.

Also, if you don't want to be perceived unempathic and entitled, start by not calling other people that provide you with feedback as "pal".

@Nmeri17 The project, as maintained, already solves a certain problem and vision. While it might seem that "if it can do x it should also do y", it also means adding another layer of complexity making the entire thing harder to maintain. Ever heard of "feature creep"? It's sometimes hard enough to keep a project grounded in a certain way as it is. A lot of libraries are very focused to actually keep their scope to a minimum and outright say what they will never do. You might not agree with their stance, your use case might be very valid, still it's their prerogative on how to progress with their project and it's your prerogative to fork them and push the project in a different direction.

There is a sense of entitlement in a lot of the issues being created on open source projects.

People spend either their free time working on a public library or they are, at best, paid by some stakeholder to maintain the project in a certain direction which need not align with yours.

If you want, you may ask for the feature. Yet at no point are you entitled for them to implement it for you.

I also understand it's not always feasible to implement it yourself, or sometimes some projects shoot feedback down in a way that feels unwelcome.

Yet there is a level of abuse here that a lot common programmers just seem oblivious of.

If you really need it: Code it yourself, pay them to code it for you, pay somebody else to code it for you.

There's always a cost in wanting to live unlike the majority.

It sure is possible to live without a smartphone but damn hell it's an inconvenient one nowadays.

It's always the question on which battle you want to fight, but the fight against the smartphone will most likely be a very lonesome hill to die on.

Product owner should not vote. If the cost of a story is too high, well, tough luck. They can still decide to not add in the sprint.

They should also not lead in with loaded statements like "let's estimate this easy story".

And oh: If I vote high and another one votes very low my go-to-statement is: "You got the job."

But beyond the ranting: A team should argue about the disparity of estimates. As that may lead to clarify one's assumption. One should come to the same number after multiple rounds of voting, but not like this. If one cannot find a common ground, a spike meeting may be a good idea to delve deeper in order to make a more informed estimation.

You don't want my bugfix running on production that was written while I was hangry.

Unless we are talking business-sinking incidents, it's completely fine for a hotfix wait for another hour so people can have their lunch.

You know, you could get caffeine pills in order to take in way less sugar?

That being said: Be careful, caffeine is also an addiction and you may get serious symptoms if you overdo it (heart racing, nervousness, anxiety, headaches).

Also, your body will build a tolerance towards caffeine and if taken everyday, you will need higher and higher doses.

Maybe, you should do a complete abstinence from caffeine for two weeks. Then the next small energy drink will have a powerful punch.

`y` ain't `Y` ^^

If you don't want to be interactive, rather run `sudo apt dist-upgrade -y`, there it is lowercase.

If you are difficult and arrogant, you are not good at your job. Soft skills count at least the same if not more than hard skills.

At first, give them feedback that their behavior is unacceptable for the workspace, and if they accept it and change, all is well. If they chose to ignore it, let them go.

Also: Don't forget their effect on other colleagues. A decent employee adds, a great one multiplies by setting the potential of others free, a bad one substracts, or even worse, divides by poisoning entire teams. I've seen entire teams leaving a company because somebody toxic was allowed to stay in a central position. It can escalate from there.

The SSD is most likely skewing your perception of the increased performance. Replacing a HDD with a SSD is the single most best upgrade anyone can do to their old laptop.

My girlfriend couldn't believe that her almost a decade old laptop could and would boot up in under 15 seconds (as opposed to almost 2 minutes before having a usable state).

That being said: I am definitely no apple fanboy. I had to work with it for 1.5 years and the experience was annoying (homebrew mess, docker slowness due to virtualization layer) and stupid defaults that made customizing the window manager a necessity (that stupid fullscreen button since Yosemite requiring extra tools like Specacle / Rectangle).

I am much happier working on a Linux machine and gaming on a Windows PC.

I used to have one 30-inch monitor, now I working in a combination of 15" Thinkpad, plus 30" monitor, and my old trusted 22" monitor as a sidepanel that I can pivot by 90 degrees.

You do you. I don't hate the fullstack developer, I hate companies hiring one fullstack developer expecting them to do the job of entire teams. It's why I avoid fullstack positions as best as I can.

Very often comments are redundant and code smell. I truly hate code that reads

const length = 20; // length in cm

There is no excuse not to write at least:

const length_in_cm = 20;

(You could drive this point further with a class that both stores value and unit and is able to switch between units.)

I really don't need comments to repeat code that has been written.

// define a number with 0
const number: int = 0;
// increase the number by one
number += 1;

That is just irritating. And it will grow apart:

// increase the number by one
number += 3;

Who is right? The comment or the code? Just delete the comment here!

Though while good code is a self-commenting as possible, code will never tell you WHY it's doing things. It explains the HOW and the WHAT. (Unit tests do not necessarily explain the WHY as well. They just define seemingly correct behavior.)

It's helpful to explain the counter-intuitive aspects to your colleagues to not force them to go through the same journey.

@noyb My entire mistake was falsely using `assertJson` over the correct `assertJsonStringEqualsJsonString` to begin with.

There is no evaluation going on.

`assertJson` will succeed if the first argument is a valid json (and as I pass in my $expected that is always a valid json it will always be true) and the second one is then merely the message phpunit would print if an error was to occur which was my actual JSON payload to test against.

@LLAMS You know what I hate about our industry?

The lack of ability to recieve feedback and while giving it, the lack of taking a good-reasons approach.

Did I make a mistake in parsing the image. Yes I did and from that misconception on I completely missed the point. I can see that and I do feel sorry for that. You could have pointed that out like the others who kindly did it.

Yet why do you assume I wrote what I have written simply from a ego-flexing point and take offense? Why do you have to take a moral highground?

I referenced my very own struggle as a beginner when trying to grasp OOP myself. I did not intend to block somebody on their path but pointing out where I hit a confusing block in the way OOP is commonly taught in hopes they can avoid that confusion from the very beginning.

@GIS-Jedi Sorry for that. I misread your graph on that part and argued against a strawman of my own creation. I wanted to give feedback and I like to apologize if my wording was too strong.

I get that you use the graph for visual learning and I gave you +1 for it.

But you have to realize that you are modelling *inheritance*. It's an aspect allowed by OOP. Yet OOP !== Inheritance. And inheritance almost always has better alternatives.

I like to think of OOP as one way of dealing with the problem of mutability while avoiding a global state. You encapsulate your mutable states and you abstract the usage from its implementation.

(One of the first rookie's mistake in OOP is that everything is public. Or if it isn't, every properly will have public setters. A complete maddening antipattern. Often showcased in those oop inheritance examples.)

Interfaces and composition are so much more important concepts to understand when trying to grog OOP.

Recently, I delved into functional programming more and also noted how it's affected the way I write OOP code. If I can make a method pure, it will be and I embrace immutability wherever I can.

I don't really want to rain on your parade, yet one of my biggest problems when learning OOP was the real-world-examples. You almost never model cars, or shelves, or animals that way.

And once you delve deeper into OOP basically everybody is like "beware of inheritance" because the inheritance tree is not very flexible (it creates strongly coupled classes) and you shoot yourself in the foot very easily.

And while I would not call it evil, there are almost always more fitting patterns available for your polymorphism besides inheritance.

This leads to the strange fact that inheritance is one of the earliest thing one learns in OOP, yet it's the one I use the rarest.

Design patterns at their worse are buzzwords mostly needed to pass the job interview. Design patterns at their best are tools in your repertoire to help you shape your code before you write any as you can wrap similar problems in appropriate code.

That being said: it really depends on what you want to build and what trade offs you are after.

There's no silver bullet.

That seems ill-advised. What kind of smartphone do you have that it is more powerful than your laptop? ^^

In Germany, web.de is the worst provider. I'm waiting for those pour souls that subscribed to their premium package by accident decades ago to die so that this petty excuse for a provider finally can go bankrupt.

I completely understand the rationale for language-based stackexchange platforms, yet still I can't stop but feel sad about the babel-ian fragmentation.

I always liked the concept of all the people coming together and working on a huge resource for programming.

Yet it's also a very anglocentric perspective (even though I am German).

@devdiddydog Also writing "more" test is not the solution. Test coverage should not change depending on an approval requirement.

Furthermore, having your tests peer reviewed provides your teammates with the opportunity to understand your assumptions and to correct them.

Your teammates are either too busy doing normal work that they can't properly approve. That means you all need dedicated time for reading reviews. (My last team was like: The hour after the daily standup is reserved for PR.)

It may be that they don't consider it fun or beneficial which is a huge red flag as that indicates that they don't understand the reason and impact of doing proper reviews. ("What a waste of time.")

Or it may even be that nobody in a team has a real clue what the other is doing and that they even are unable to do proper reviews. ("Looks good to me. Approved.")

There is so much to be discovered why people are apathetic about doing pull reviews. That doesn't make the artifact a bad one.