So I told my wife one week ago: "Yeah, you should totally learn to code as well!"

Yesterday a package arrived, containing a really beautiful hardcover book bound in leather, with a gold foil image of a snake debossed into the cover, with the text "In the face of ambiguity -- Refuse the temptation to guess" on it.

Well, OK, that's weird.

My wife snatches it and says: "I had that custom made by a book binder". I flip through it. It contains the Python 3.9 language reference, and the PEP 8 styleguide.

While I usually dislike paper dev books because they become outdated over time, I'm perplexed by this one, because of how much effort and craftsmanship went in to it. I'm even a little jealous.

So, this morning I was putting dishes into the dishwasher, and she says: "Please let me do that". I ask: "Am I doing anything wrong?"

Wife responds: "Well, it's not necessarily wrong, I mean, it works, doesn't it? But your methods aren't very pythonic. Your conventions aren't elegant at all". I don't think I've heard anyone say the word "pythonic" to me in over a decade.

And just now my wife was looking over my shoulder as I was debugging some lower level Rust code filled with network buffers and hex literals, and she says: "Pffffff unbelievable, I thought you were a senior developer. That code is really bad, there are way too many abbreviated things. Readability counts! I bet if you used Python, your code would actually work!"

I think I might have released something really evil upon the world.

The effect of too much rubber duck debugging.

Just found out the backend developer I’m always complaining about. The one who:

- Can’t implement OAuth, and we have to have app users login every 24 hours because we have no way to generate new refresh tokens.

- Who used the phrase “your time zone is not my concern” to avoid building something that would let us inject test data.

- Who’s been debugging a critical bug affecting many users since December.

- Who can’t conduct API tests from external internet (you know, like the way the app will be in the wild) because it takes too much time.

- Who replies to Jira tickets only on a blue moon.

- Who has been 90% of the reason for my blood pressure situation

... is a fucking principal engineer in this company. In pecking order, his opinion should be considered more valuable than mine and everyone on my team.

I’ve just lost the will to live. How are big organizations THIS bad. Seriously, what promotion discussion did he go into

“So, you are a complete and utter bastard, nobody can stand to speak to you and you’ve yet to deliver anything of worth that actually works, over the course of several years ... ... ... interested in having your pay doubled??”

Goddamn I'm retarded to the next level.

Rebooted my phone a few days ago, some stuff didn't work well anymore and I'm looking for a new one which supports custom roms but I shouldn't spend too much right now so I thought I'd let it go for now.

Rebooted again last night and the network time wouldn't set properly so set it manually. Today I suddenly noticed that any app/page loading through a secure connection wasn't loading at all.

This to the goddamn point that my phone was becoming useless.

Started to search for a quick, cheap replacement supporting custom roms while debugging on and on.

I just (now) looked at the date and BAM, it hit me: I set it to one month earlier.

Mother of god I'm stupid. Brain fart to the max.

"Don't worry about the little things."

- Programmer, never.

Spent way too much time debugging and the issue was a missing exclamation mark - once again.

It's always the little things!

Short version:

Dear devRantdairy,
today I was stupid.

The End.

Full version:

I am working on some messaging system, trying to use less as possible overhead sending data. Therefore there of course are asynchronous calls and some templating. But that's just the setting of the rant: I designed an architecture to save conversations in a database. Working with transactions in pdo I wrote a query wich in my eyes should have worked well. But the result just didn't appear in the table. So I started debugging data. Recreated the table. Rewrote the query. Went to bed. Woke up. Further tryed to make this work. And in the end I realized I just forgot to commit the transaction.

How dumb can you be? There's way too much time gone for that mistake. Is there a hole? I want do dig myself.

People say programmers are no fun!! But they don't know the truth.

We have big Ass container of emotions almost ready to explode anytime. We are spending too much time in debugging stuff one after another that having a free time is just a hoax to us, even when we came back home for sleep, it's only to dream about solution. We would be happy with debugging the error that is not letting us sleep for weeks.

!rant
Our lead dev in the company seems to be a smart guy who's sensitive about code quality and best practices. The current project I'm working on (I'm an intern) has really bad code quality but it's too big an application with a very important client so there's no scope of completely changing it. Today, he asked me to optimize some parts of the code and I happily sat down to do it. After a few hours of searching, profiling and debugging, I asked him about a particular recurring database query that seemed to be uneccesarilly strewn across the code.
Me: "I think it's copy pasted code from somewhere else. It's not very well done".
Lead Dev: "Yeah, the code may not the be really beautiful. It was done hurriedly by this certain inexperienced intern we had a few years back".
Me: "Oh, haha. That's bad".
Lead Dev: "Yeah, you know him. Have you heard of this guy called *mentions his own name with a grin*?"
Me: ...
Lead Dev: "Yeah, I didn't know much then. The code's bad. Optimize it however you like. Just test it properly"
Me: respect++;

I'll use this topic to segue into a related (lonely) story befitting my mood these past weeks.

This is entire story going to sound egotistical, especially this next part, but it's really not. (At least I don't think so?)

As I'm almost entirely self-taught, having another dev giving me good advice would have been nice. I've only known / worked with a few people who were better devs than I, and rarely ever received good advice from them.

One of those better devs was my first computer science teacher. Looking back, he was pretty average, but he held us to high standards and gave good advice. The two that really stuck with me were: 1) "save every time you've done something you don't want to redo," and 2) "printf is your best debugging friend; add it everywhere there's something you want to watch." Probably the best and most helpful advice I've ever received 😊

I've seen other people here posting advice like "never hardcode" or "modularity keeps your code clean" -- I had to discover these pretty simple concepts entirely on my own. School (and later college) were filled with terrible teachers and worse students, and so were almost entirely useless for learning anything new.

The only decent dev I knew had brilliant ideas (genetic algorithms, sandboxing, ...) before they were widely used, but could rarely implement them well because he was generally an idiot. (Idiot sevant, I think? Definitely the idiot part.) I couldn't stand him. Completely bypassing a ridiculously long story, I helped him on a project to build his own OS from scratch; we made very impressive progress, even to this day. Custom bootloader, hardware interfacing, memory management, (semi) sandboxed processes, gui, example programs ...; we were in highschool. I'm still surprised and impressed with what we accomplished.

But besides him, almost every other dev I met was mediocre. Even outside of school, I went so many years without having another competent dev to work with. I went through various jobs helping other dev(s) on their projects (or rewriting them), learning new languages/frameworks almost every time: php, pascal, perl, zend, js, vb, rails, node, .... I learned new concepts occasionally (which was wonderful) but overall it was just tedious and never paid well because I was too young to be taken seriously (and female, further exacerbating it). On the bright side, it didn't dwindle my love for coding, and I usually spent my evenings playing with projects of my own.

The second dev (and one one of the best I've ever met) went by Novo. His approach to a game engine reminded me of General Relativity: Everything was modular, had a rich inheritance tree, and could receive user input at any point along said tree. A user could attach their view/control to any object. (Computer control methods could be attached in this way as well.) UI would obviously change depending on how the user could interact and the number of objects; admins could view/monitor any of these. Almost every object / class of object could talk to almost everything else. It was beautiful. I learned so much from his designs. (Honestly, I don't remember the code at all, and that saddens me.) There were other things, too, but that one amazed me the most.

I havent met anyone like him ever again.

Anyway, I don't know if I can really answer this week's question. I definitely received some good advice while initially learning, but past that it's all been through discovering things on my own.

It's been lonely. ☹

TL;DR: At a house party, on my Phone, via shitty German mobile network using the GitLab website's plain text editor. Thanks to CI/CD my changes to the code were easily tested and deployed to the server.

It was for a college project and someone had a bug in his 600+ lines function that was nested like hell. At least 7 levels deep. Told him before I went to that party it's probably a redefined counter variable but he wouldn't have it as he was sure it was an error with the business logic. Told him to simplify the code then but he wouldn't do that either because "the code/logic is too complex to be simplified"... Yeah... what a dipshit...
Nonetheless I went to the party and He kept debugging. At some point he called me and asked me to help him the following day. Knowing that the code had to be fixed anyways I agreed.
I also knew I wouldn't be much of a help the next day due to side effects of the party, so I tried looking at this shitshow of a function on my phone. Oh did I mention it was PHP, yet? Yeah... About 30 minutes and a beer later I found the bug and of course it was a redefined counter variable... My respect for him as a dev was already crumbling but it died completely during that evening

I am thinking about leaving this platform. To be honest I don't get anything out of it anymore and the only thing keeping me here is the less-rant'ish content like @devNews or the stories.

I am actually a bit disappointed, the quality of devrant really did degrade alot in the last few months. Don't get me wrong but I feel like people have become "normies" over here. I don't mean that in an edgy or degrading way but let me explain. When I started here I had a very high opinion of the people here. Everyone seemed like a passionate / knowledgeable individual from whom you could hear interesting stories or learn. Maybe I just saw it like that because I was still a very inexperienced dev and was looking for a dev community. But nonetheless I think devRant transformed into a place of mediocrity.

Dont get me wrong I wouldn't think of myself as aspiring or generally "better" than anyone else on here, but the content over here got a little stale.

I am not the kind of person who would "rant", in the first place, so I may have a different mindset and to be honest "ranting" has always been a thing I looked down upon. It just does not support my style of thinking. I totally get that people sometimes need to "vent" their feelings but there is nothing productive to gain from ranting, like you ain't not improving your situation by doing it. The more passionate raters over here call people things, I would never even dream about saying to people. Don't worry I'm no sjw or something like it, I don't care if you do it. If it helps you sure, why not. But there is a point where you corner yourself so much that you stop respecting your colleagues because they wrote that shitty code, instead of helping.

Some tech sure is bad, but it is not getting any better by insulting it.

Another thing I use to notice are people, thinking so highly of them selfes / being so close-minded - that they only accept their own views as true. These are the people that I always try to avoid, but that is getting harder and harder as time goes on.

Collectivism and group thinking are very strong on devRant making it really hard to defend a unpopular opinion - I get that devRant is not the kind of platform that would support actual proper arguments/discussions - but I still feels like some people shove opinions down another people's throat with no reasoning behind it.

Arguments on devRant are always won by the person coming up with the most witty response. Having another opinion is always seen as offensive. That's not exactly the definiton of open-mindedness.

Another rather annoying thing are what I call the "non dev, dev's". See: As a developer you should aspire to understand what your doing - I won't get into this too much but one sentencd: How are things like serious "Semicolon memes" a thing? I am as much into memes as the next guy, but debugging 3 hours, just to find out its a typo. I mean come on...

I sure get that devRant is not the kind of place where you would find the people I am looking for, and that's why I am leaving.

My whole post may seem super negative of the platform - and it is to an extend - but I sure also had a good time back in the day - devRant as in "the platform" surely is not at fault, but a forum is only as good as the people on it. Maybe I changed, maybe devRant did. All I know is that it is not for me anymore.

I won't delete my account and I probably will not leave completely, but all I will do is the "once a week" checkout.

I've been away from devRant (and other social media) for a few days because I thought i needed to concentrate on a project that I'm currently working on.

I just realized that I need this, I really need to rant! There is just too much to rant about. Like how fuckin annoying tomcat is, (don't ask me, someone is paying for me to use it), or how eclipse is happily hugging over 1gb of my ram, ( again don't ask), meanwhile vscode is doing just the same thing (debugging a tomcat server) with less than 300mb! There's so much to be annoyed about that I truly don't know how I was getting along before devRant.

Need to rant / maybe some advice.

Working remote is hard.
New company, remote on boarding. I feel like my coworkers are robots, and I'm being tossed into the deep end with minimal guidance.

The codebase is so unnecessarily complicated, its impossible to read. I've been trying to figure out how things work for a whole month, still not sure.

My mentor that is supposed to help onboard me is a robot, and answers questions in a somewhat acceptable manner, but it still feels like a lot of "figuring out" is still left for myself.

My other work partner that is also a newbie like myself is also a robot - doesn't talk or ask many questions whenever we have a sync up meeting.

The codebase is huge and feels quite overwhelming, I don't feel like I got a team "with my back", I don't enjoy work as much as I have before, I barely do any coding (mostly reading code and trying to understand how everything is working by setting breakpoints and debugging tests that take foreeeever to run), and some days I'm seriously considering cutting my losses and jumping ship just to save my sanity.

Am I paranoid? Am I just dumb? Should I just suck it up and be happy I have a job? Is this how Remote work is supposed to feel like? Why does it feel like my soul is dying?

Anyone in similar situations, or who can give some insight/advice/etc, I would highly appreciate it.

And this is supposed to be a good company too from the reviews. I don't know how it can be so crappy in reality. Did I make the wrong choice joining? Should I jump ship sooner rather than later? I've only been here about a month or so, and maybe its too soon? Halp!

My Gripe With Implicit Returns

In my experience I've found that wherever possible code should be WYSIWYG in terms of the effects per statement. Intent and the effects thereof should always be explicit per statement, not implicit, otherwise effects not intended will eventually slip in, and be missed.
It's hard to catch, and fix the effects of a statement intent where the statement in question is *implicit* because the effect is a *byproduct* of another statement.

Worse still, this sort of design encourages 'pyramid coding recursion hell', where some users will first decompose their program into respective scopes, and then return and compose them..atomically as possible, meaning execution flow becomes distorted, run time state becomes dependent not on obvious plain-at-sight code, but on the run time state itself. This I've found is a symptom of people who have spent too much time with LISP or other eye-stabbingly fucky abominations. Finally implicit returns encourage a form of thinking where programmers attempt to write code that 'just works' without thinking about how it *looks* or reads. The problem with opaque-programming is that while it may or may not be effortless, much more time is spent in reading, debugging, understanding, and maintaining code than is spent writing it--which is obviously problematic if we have a bunch of invisible returns everywhere, which requires new developers reading it to stop each and every time to decide whether to mentally 'insert' a return statement.

This really isn't a rant, as much as an old bitter gripe from the guy that got stuck with the job of debugging. And admittedly I've admired lisp from afar, but I didn't want to catch the "everything is functional, DOWN WITH THE STATE" fever, I'm no radical.

Just god damn, think of the future programmer who may have to read your code eventually.

Here's my new function:

/**
* Output Debugging information and Die
*
* @return hopefully
*/
public function odd()
{
//stuff here
}

Hopefully, you don't have to ODD too much when you write code... like I have to do right now

fuck sakes

Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.

So i wasted last 24 hours trying to satisfy my ego over a shitty interview and revisiting my old job's codebase and realising that i still don't like that shit. just i am 25 and have no clue where am i heading at. i am just restless, my most of the decisions in 2023 have given very bad outcomes and i am just trying doing things to feel hopeful.

context for the interview story-----
my previous job was at a b2b marketing company whose sdk was used by various startups to send notifications to their users, track analytics etc. i understood most of it and don't find it to be any major engineering marvel, but that interviewer was very interested in asking me to design a system around it.

in my 1.2 years of job there, i found the codebase to be extremely and unnecessarily verbose ( java 7) with questionable fallbacks and resistance towards change from the managers. they were always like "we can't change it otherwise a lot of our client won't use our sdk". i still wrote a lot of testcases and tried to understand the working of major features.

BTW, before you guys go on a declare me an embarrassment of an engineer who doesn't know the product's code base, let me tell you that we are talking SDKs (plural) and a service based company here. their was just one SDK with interesting, heavy lifting stuff and 9 more SDKs which were mostly wrappers and less advanced libraries. i got tasks in all of them, and 70% of my time went into maintaining those and debugging client side bugs instead of exploring the "already-stable-dont-change" code base.

so based on my vague understanding and my even more vague memory from 1 year ago, i tried to explain an overall architecture to that interviewer guy. His face was screaming the word "pathetic" from his expressions, so i thought that today i will try to decode the codebase in 12-15 hours, publish a cool article and be proud of how much i know a so called martech system design. their codebase is open sourced, so it wasn't difficult to check it out once more.
but boy oh boy i got so bored. unnecessary clases , unnecessary callbacks static calls , oof. i tried to refactor a few classes, but even after removing 70% of codebase, i was still left with 100+ classes , most of them being 3000-4000 files long. and this is your plain old java library adding just 800kb to your project.

boring , boring stuff. i would probably need 2-3 more days to get an understanding of complete project, although by then i would be again questioning my life choices , that was this a good use of my 36 hours?

what IS a correct usage of my time? i am currently super dissatisfied with my job, so want to switch. i have been here for 6 months, so probably i wouldn't be going unless i get insane money or an irresistible company offer. For this i had devised a 2 part plan to either become good at modern hot buzz stuff in my domain( the one being currently popularized by dev influenzas) or become good at dsa/leetcode/cp. i suck bad at ds/algo stuff, nor am i much motivated. so went with that hot buzz stuff.

but then this interview expected me to be a mature dev with system design knowledge... agh fuck. its festive season going on and am unable to buy any cool shirts since i am so much limited with my money from my mediocre salary and loans. and mom wants to buy a home too... yeah kill me

Was resolving some katas on codewars because I was tired... Ok I guess I've got too much debugging

A bit late.. and not much about how to learn to code..but more of a figuring out if the kid has a right mind set to do so..

If the kid is not the type to question everything, not resourceful, not a logical/critical thinker, gives up easily and especially if not interested in how things work then being a dev is most probably not for them.. they can still persue coding, but it will end badly..

From my experience, people who have a better education than me, but lack those skills turned out to be a crappy dev.. not interested in the best tool to complete the tasks, just making 'something', adding more shit to the already shitty stack.. and being happy with that.. which of course is not the best way to do things around here..or in life!!

Soo.. if the kid shows all that and most importantly shows interest in learning to code.. throw him the java ultimate edition book and see what happens.. joke!

There are plenty of apps thath can get you started (tried mimo, but being devs yourself it's probably not so hard to check some out and weed out the bad ones) that explain simple logic and syntax.. there is w3schools that explains basics quite well and lets you tinker online with js and python..
so maybe show them these and see what happens.. If it will pick their interest, they will soon start to ask the right questions.. and you can go from there..

If the kids are not the 'evil spawns' of already dev parents or don't have crazy dev aunties and uncles, then they will have to work things out themselves or ask friends... or seek help online (the resourceful part comes here).. so google or any flavour of search engines is their friend..

Just hope they don't venture to stack overflow too soon or they will want to kill themselves /* a little joke, but also a bit true.. */

Anyhow, if the kid is exhibiting 'dev traits' it is not even a question how to introduce it to the coding.. they will find a way.. if not, do not force them to learn coding "because it's in and makes you a lot of moneyz"..
As with other things in life, do not force kids to do anything that you think will be best for them.. Point them in direction, show them how it might be fun and usefull, a little nudge in the right direction.. but do not force.. ever!!!

And also another thing to consider.. most of the documentation and code is written in english.. If they are not proficient, they will have a hard time learning, checking docs, finding answers.. so make sure they learn english first!!
Not just for coding, knowing english will help them in life in general. So maaaaybe force them to learn this a bit..

One day my husband came to me and asked me how he can learn.. and if it's too late for him to learn coding.. that he found some app and if I can take a look and tell him what I think, if it is an ok app to learn..
I was both flattered and stumped at the same time..
Explained to him that in my view, he is a bit old to start now, at least to be competitive on the market and to do this for a living, but if it interests him for som personal projects, why not.. you're never too old to start learning and finding a new hobby..

Anyhow, I've pointed out to him that he will have to better his english in order to be able to find the answers to questions and potential problems.. and that I'm happy to help where and when I can, but most of the job will be on him.

So yeah, showed him some tutorials, explained things a bit.. he soon lost interest after a week and was mindblown how I can do this every day..

And I think this is really how you should introduce coding to kids.. show them some easy tutorials, explain simple logic to them.. see how they react.. if they pick it up easily, show them something more advanced.. if they lose interest, let them be.

To sum up:
- check first if they really want to learn this or this is something they're forced to do (if latter everything you say is a waste of everybodys time)
- english is important
- asking questions (& questioning the code) is mandatory so don't be afraid to ask for help
- admitting not knowing something is the first step to learning
- learn to 'google' & weed out the crap
- documentation is your friend
- comments & docs sometimes lie, so use the force (go check the source)
- once you learn the basics its just a matter of language flavour..adjust some logic here, some sintax there..
- if you're stuck with a problem, try to see it from a different angle
- debugging is part of coder life, learn to 'love' it

i never knew id reach that point when i need to take a break from programming and everything that has been causing me so much stress for the past few days. and to be honest, it actually feels great to be focused on only one thing instead of stressing out on different projects and debugging them all at once.

in a few days, ill prolly go back to programming some side projects. its not like i can keep myself away from them...

programming is like a magnet for. that magnetic force is growing stronger day by day and im being pulled closer to it. im happy about it except for some occasions when i get too stressed.

I'm helping my teammates with the problems that they face in debugging an issue or fixing a Dev environment.

Sometimes ppl go too flexible and ask for my Dev VM. The help I have to offer is tell them cause of an issue and tell them the fix that they have to give. What the fu*k they do? What did they gain as experience all these years.

Ppl don't know how to make draft commits. They can't fix but failures. They don't know anything.
They just sit at office and age as it is their only job.
Seniors take so much salary. Why don't they feel bad that they are not doing justice to their work.

For me coding is a huge part of my mindset. I could be having a conversation with a gf and be debugging an issue in my head. I could wake up in the middle of the night and start coding an idea I had just thought of. Especially if I'm working on something I'm too excited about, I will work hours, days straight and not make time for much else. So I've phased through quite a few relationships this way (especially with normies) 🤷‍♂️ I almost feel like I'd have to be with someone as obsessed as I am for things to work out lol

OCD driven development
- level of recursion determined by how much the algorithm bothers you
- too much and nothing is ever finished
- not enough and code is shitty and unmaintainable
- can result is longer variable names
- takes longer to name a variable
- text slightly misaligned requires hours of debugging time
- balanced by "OMFG that will take forever to fix" Sometimes...
- can lead to unobjective code reviews

Having a lot of bad experiences while working as intern in startups and about to join a MNC, i wanted to share my work life balance and technical demands that i expect from a company. These are going to be my list of checkpoints that i look forward , let me know which of them are way too unrealistic. also add some of yours if i missed anything :

Work life balance demands ( As a fresher, i am just looking forward for 1a, 2a and 8, but as my experience and expertise grows, i am looking forward for all 10. Would i be right to expect them? ):

1a 8 hr/day. 1b 9h/day
2a 5days/week. 2b 6 days/week
3 work from home (if am not working on something that requires my office presence)
4 get out of office whenever i feel like i am done for the day
5 near to home/ office cab service
6 office food/gym service
7 mac book for working
8 2-4 paid leaves/month
9 paid overtime/work on a holiday
10.. visa sponsorship if outside india

Tech Demands (most of them would be gone when i am ready to loose my "fresher " tag, but during my time in internship, training i always wished if things happened this way):

1. I want to work as a fresher first, and fresher means a guy who will be doing more non tech works at first than going straight for code. For eg, if someone hires me in the app dev team, my first week task should be documenting the whole app code / piece of it and making the test cases, so that i can understand the environment/ the knowledge needed to work on it

2. Again before coding the real meaningful stuff for the main product, i feel i should be made to prepare for the libraries ,frameworks,etc used in the product. For eg if i don't know how a particular library ( say data binding) used in the app, i should be asked to make a mini project in 1-2 days using all the important aspects of data binding used in the project, to learn about it. The number of mini tasks and time to complete them should be given adequately , as it is only going to benefit the company once am proficient in that tech

3. Be specific in your tasks for the fresher. You don't want a half knowledgeable fresher/intern think on its own diverging from your main vision and coding it wrong. And the fresher is definitely not wrong for doing so , if you were vague on the first place.

4. most important. even when am saying am proficient , don't just take my word for it. FUCKIN REVIEW MY CODE!! Personally, I am a person who does a lot of testing on his code. Once i gave it to you, i believe that it has no possible issues and it would work in all possible cases. But if it isn't working then you should sit with me and we 2 should be looking, disccussing and debugging code, and not just me looking at the code repeatedly.

4. Don't be too hard on fresher for not doing it right. Sometimes the fresher might haven't researched so much , or you didn't told him the exact instructions but that doesn't mean you have the right to humiliate him or pressurize him

5. Let multiple people work on a same project. Sometimes its just not possible but whenever it is, as a senior one must let multiple freshers work on the same project. This gives a sense of mutual understanding and responsibility to them, they learn how to collaborate. Plus it reduces the burden/stress on a single guy and you will be eventually getting a better product faster

Am i wrong to demand those things? Would any company ever provide a learning and working environment the way i fantasize?

Hi there!

I've been worrying about the following problem for months now and I don't find any solution. Maybe anybody of you can lead me the way.

We are developing a software suite which consists of a number of desktop applications:

* 12 applications written in C++; all over 20 years old; further development by 5 or 6 guys (one man armys) - mainly bugfixing, changes of law implementations, small features
* 2 applications we are currently writing in C#; completely new developments of existing C++ applications; scrum teams with at least 5 guys; this is, where we put our focus in

These applications (C++ and C#) are sharing some core assemblies and are interacting with each other. So they are not independent.

We organize them in a mono repository in one huge solution, which consists currently of about 500 projects.

Advantages:

* With all projects in one solution and through project references, Visual Studio takes care of the right build order
* Code navigation is superb - every single line of code is accessible - this makes refactoring easy
* Every developer can map the branch and build the whole suite locally
* Debugging on the local machine is easy
* DevOps pipeline is straight forward - it just have to build a single solution

Disadvantages:

* The huge solution is extremely slow.
* If you want to build the solution or you want to debug (which does essentially the same as a pre step) Visual Studio is building a lot of projects, although they haven't been changed. Their detection is buggy. So sometimes you wait 2 minutes until it starts the app. That slows us down a lot.
* Full builds need about an hour, because its building the same projects (even if they haven't been changed) over and over again (with ready made nuget packages this could be improved a lot I think)
* If a core team member changes some core apis, he is changing the calling code too, although he doesn't know the calling code, because another team has written it. I don't think, that's best practice and it doesn't scale.
* Often, a C# developer has to mess around with C++ building problems, because the C++ projects are in the same solution
* It gets more and more confusing and frustrating, because there is no clear organizational seperation between apps and nobody can't just focus on his app alone.

Idea:

I was thinking about putting the whole framework and core projects in a new solution (around 100 projects). Then we could take all old C++ projects and put them also in a new solution (around 200 projects). This would leave the newer projects (new applications - C#) in the existing solution.

This should speed up things, and would be a first step to better seperation, BUT:

How should the integration process look like?

Scenario: Core team is changing an API in our framework

Current process: Because all projects are in the same solution, they change the calling code too. So it's immediately integrated and the app developers just have to do "get latest".

New process (?): Core team is providing the changes through a nuget package (new version). So does every developer now has to keep track of if there is a new package version and if yes, do the integration? And how can we coordinate the different teams, so they are upgrading all at the same time? Because we ship our applications as a suite, all apps has to use the same versions. Or should we automate the integration process? Is there a best practice?

I have to add, that our core team is making changes very frequently, so the integration process will have to happen often.

Any ideas/feedback/inspiration?

Thank you so much in advance!

Compromise.

I think that sums up development pretty much.

Take for example coding patterns: Most of them *could* be applied on a global scale (all products)… But that doesn't mean you *should* apply them. :-)

Find a matching **compromise** that makes specific sense for the product you develop.

Small example: SOLID / DRY are good practices. But breaking these principles by for example introducing redundant code could be a very wise design decision - an example would be if you know full ahead that the redundancy is needed for further changes ahead. Going full DRY only to add the redundancy later is time spent better elsewhere.

The principle of compromise applies to other things, too.

Take for example architecture design.

Instead of trying to enforce your whole vision of a product, focus on key areas that you really think must be done.

Don't waste your breath on small stuff - cause then you probably lack the strength for focusing on the important things.

Compromise - choose what is *truly* important and make sure that gets integrated vs trying to "get your will done".

Small example: It doesn't really matter if a function is called myDingDong or myDingDongWithBells - one is longer, other shorter. Refactoring tools make renaming a function an easy task. What matters is what this function does and that it does this efficiently and precise. Instead of discussing the *name* of the function, focus on what the function *does*.

If you've read so far and think this example is dumb: Nope... I've seen PR reports where people struggled for hours with lil shit while the elephant in the room like an N+1 problem / database query or other fundamental things completely drowned in the small shit discussion noise.

We had code design, we had architecture... Same goes for people, debugging, and everything else.

Just because you don't like what weird person A does, doesn't mean it's shit.

Compromise. You don't have to like them. Just tolerate them. Listen. Then try to process their feedback unbiased. Simple as that. Don't make discussions personal - and don't isolate yourself by just working with specific persons. Cause living in such a bubble means you miss out a lot of knowledge and insight… or in short: You suck because of your own choices. :-)

Debugging... Again compromise: instead of wasting hours on debugging a problem, ASK for help. A simple: Has anyone done debugging this before or has some input for how to debug this problem efficiently?... Can sometimes work wonders. Don't start debugging without looking into alternative solutions like telemetry, metrics, known problems etc.
It could be a viable, better long term solution to add metrics to a product than to debug for hours ... Compromise. Find a fitting approach to analyze a problem instead of just starting a brute force approach.

....

Et cetera et cetera.

What we will miss, if he really softens:

In fact, if the reason is stated as "it makes debugging easier", then I fart in your general
direction and call your mother a hamster.

In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people.

Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE F*CKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the f*ck does idiotic things like that? How did they not die as babies, considering
that they were likely too stupid to find a tit to suck on?

Gnome seems to be developed by interface nazis, where consistently the excuse for not doing something is not "it's too complicated to do", but "it would confuse users".

I think the stupidity of your post just snuffed out everything

I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

That is either genius, or a seriously diseased mind. - I can't quite tell which.

Christ, people. Learn C, instead of just stringing random characters together until it compiles (with warnings).

"and anybody who thinks that the above is

(a) legible
(b) efficient (even with the magical compiler support)
(c) particularly safe

is just incompetent and out to lunch.

The above code is sh*t, and it generates shit code. It looks bad, and
there's no reason for it."