I know a lot of you already know/do this, but to those of you who don't - I know it has saved me more than once:

If you use SSMS (SQL Server Management Studio) - when connecting to a server, before you hit the "connect" button, under options, choose a color to represent which server you are connecting to. I personally use stoplight colors: red = prod, yellow = QA, green = dev....this way, it helps you realize what server you are connected to, minimizing our dreaded "oh shit" moments....lol

Hopefully this helps someone ☺

Bring the fun and curiosity back.

School education? Mostly rinse and repeat, learn from heart and do as you are told.

First job? Take these bread crumbs, shit out gold ingots, please.

There are few who had either very kind and gifted teachers / persons in their life or had a strong will / desire to learn by / for themselves - but it's hard to combine fun and curiosity with the - most of the time - very harsh reality and environment we live in.

I'd really wish that it would get back to fun and curiosity and not the endless myriad of bitching, hissing and fighting it usually is.

What I find most tiresome in education is the overflow of information with no value - most content is outdated, wrong, harmful, not precise and especially not helpful.

Thinking about good education I've got very fond memories of hanging out in IRC chats, talking with people who were "ancient" (la me 15-20, them 40 plus ;) ) and not being "shood" away, but rather getting fed by book recommendations, hints, appointments when they had more spare time to explain in private IRC sessions etc.

The atmosphere was always a "we might not have time for it, but we'll try and don't worry if you don't understand it".

When I'm trying to find information today... It's really 90 - 95 % filtering, 4 % try and error, 1 % finding what I need.

Github 101 (many of these things pertain to other places, but Github is what I'll focus on)

- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.

- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.

- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".

- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.

- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.

- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....

- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.

- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.

- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.

- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.

- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).

- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.

- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)

I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!

Not specifially one but a couple of minor mentoring moments.

I started out at a rather small company (<10 people) with a completely new language to me (Perl).
I had some trouble following along some tasks since I wasn't familiar with Perl or generally backend stuffs at all.
So the person that was supposed to "mentor" me was just giving me tasks without any hints of how to do things, this is where my "true" mentor came in to play.
I asked him a couple of things after a few unsuccesful searches on the internet and he always seemed to have the answer to it right away! It seemed like he knew everything and I really appreciated his patience and help. He did point me in the right directions when I needed it.

He left the company about 3 months ago and I still somewhat miss his mentoring existance, as he wasn't only a code but also a life mentor.

I really hope that one day I can be just like that guy, helpful, patient and be a mentor for someone else. :)

Good code is a lie imho.

When you see a project as code, there are 3 variables in most cases:

- time
- people / human resources
- rules

Every variable plays a certain role in how the code (project) evolves.

Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.

Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.

Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.

People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?

Too many people working on one thing is only bad when there are no rules ;)

Rules. There are two different kind of rules.

Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.

Coding itself. This is a very critical thing.

Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.

Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.

Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.

Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.

If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.

Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.

There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.

Good code is a lie - because it can only exist at a certain point of time.

A codebase should be a living thing - when certain parts rot, other parts will be affected too.

The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state

!rant

I am going to my first hackathon in 2 weeks and am kind of nervous. I don't know anyone and don't have a team. I was wandering if it is a requirement to work on a project? There will be a lot of workshops and I am sure I will learn a lot even without working on a project.

If you could give me some hints on what I can expect that would be really helpful.