A rant about developers on the freebsd forum.

Creativity for modern programmers lies in the realm of system debugging.
Using all the different frameworks, one needs to learn the rules and stay in the lines.
But when something doesn't work, especially on a corner case, "OMG It broke now what!!"
Learning to look at the symptoms and figure out why is the key.
"This threw an exception because of a null pointer so I'll fix it by add if (ptr != null)" is the bandaid.
The real fix comes from
"That ptr should never be null, so why was it null?"
Root cause the problem to truly fix it.
You go to a Doctor with a headache, he gives you meds. It covers the symptom but when someone asks "why the headache" and catches the tumour...
 
and always remember to proactively leverage you synergies in favor of a more beneficial, mission critical, paradigm.

I can speak business babble. I just choose not to, because I find it disrespectful.
I'll admit, I read this, face palmed, tried to figure out what you said, face palmed again, then laughed.
 
Some languages have nullable types and provide exception handling. So this can be easily avoided.
Handling an exception requires thought on "what should the program do to handle this exception"
And yes, C++ has excellent exception handling, but it always requires thought on what to do.
 
This reminds me of a phrase generator:
1686596873918.png
 
Handling an exception requires thought on "what should the program do to handle this exception"
And yes, C++ has excellent exception handling, but it always requires thought on what to do.
The exception mechanism in C++ is a wonderful language strength, once you understand what it means to handle an exception. Even Stroustup waffled on exceptions early on. In his original language specs he considered exceptions just to be another program control path, but later on it became established dogma that execptions were for handling "exceptional situations".
 
  • Like
Reactions: mer
Not hijack the OP thread, but I think you misunderstand my point. you can't have managers and bean counters running Dev efforts. You need someone who understands and respects what the devs bring to the table (treats them like artists) and who allows them to be creative while focusing their efforts on the end goal. That model is very rare these days in business.
Just a reminder of a historical parallel: in Florence, where Michelangelo worked for a time, Medici was a sponsor. Medici had the money to sponsor a LOT of artists and scientists who worked independently. That kind of development model is unsustainable.

If artists(coders) want a sponsor, find someone like Medici(Microsoft). Yeah, you'll be given directions from time to time. If you follow directions, you won't starve. Otherwise, what you make/code up is only gonna be useful to you alone, if that. You wanna go big with your skills, be ready to give up some freedom.
 
Did Michelangelo actually give up any freedom on "how" he created his works? He took commissions, "do this in this amount of time for this much". Sponsors would stop in and look at progress but never dictated how he progressed.
Modern "development processes" often try to dictate the "how", all in the name of metrics and "I don't have any insight into you actually doing work".
Early on used to be lines of code until someone discovered that "hey, I can just add semi-colons at the end of the file and up my LOC/day metric"
Agile stuff now: I find the quick status meetings useful as long as they stay quick and focused on the status. Even the "I'm blocked by not having X" is useful. But Agile turns into too much of a public shaming "I can't do anything because he's blocking me" which is counter productive.
I've had that coversation lots of times with folks because they tell me "we hold each other accountable".
Me: Huh? No it's me publicly shaming someone for not having something done when they said they would and since I can't hire/fire, all I can do is downgrade on a review. And that seems kind of stupid to me. It makes more sense if I go talk to them one on one and see if I can help.


Otherwise, what you make/code up is only gonna be useful to you alone, if that.
I would point you at the FreeBSD project and the folks that have developed it, are developing it and will develop it. Some are making a living at it, others it's a hobby, others are in between.

Programming is a skill, a lot has to do with learning a language, but the art has always been in designing and understanding that it's the overall system that matters.
You wanna go big with your skills, be ready to give up some freedom.
Unless you sign an NDA that says "while we are paying you, you cannot work on any other software not even in your free time" you don't give up anything other than time. Someone pays you to write software to do what they want, well, fine "work for hire". At the end of the day, on your own systems, you have the freedom to do what you want.

All this is to say in my opinion, the analogy of modern developers to Michelangelo is tenuous.

And if you've actually read this far, thank you. I apologize for getting long.
 
Did Michelangelo actually give up any freedom on "how" he created his works? He took commissions, "do this in this amount of time for this much". Sponsors would stop in and look at progress but never dictated how he progressed.
Michelangelo did give up quite a bit of freedom in his works. His works were frankly pure propaganda, a way for Medici to display their wealth. Capturing imagery of poverty of the day on the streets - that was heavily discouraged by the sponsors. Even in the visible works, imagery of poverty was always on the side in Michelangelo's works.


Modern "development processes" often try to dictate the "how", all in the name of metrics and "I don't have any insight into you actually doing work".
Early on used to be lines of code until someone discovered that "hey, I can just add semi-colons at the end of the file and up my LOC/day metric"
Agile stuff now: I find the quick status meetings useful as long as they stay quick and focused on the status. Even the "I'm blocked by not having X" is useful. But Agile turns into too much of a public shaming "I can't do anything because he's blocking me" which is counter productive.
I've had that coversation lots of times with folks because they tell me "we hold each other accountable".
Me: Huh? No it's me publicly shaming someone for not having something done when they said they would and since I can't hire/fire, all I can do is downgrade on a review. And that seems kind of stupid to me. It makes more sense if I go talk to them one on one and see if I can help.
Rome was not built in a day. Even the Great Wall of China required labor of LOTS of people. If everybody wanted to write their name on every single brick (and every single brick were to be handmade by a different process), neither Rome nor Great Wall of China would happen. Writing your name on every single brick is like (trying to insist on using subversion or MacBook Pro or Ruby to work on FreeBSD, or insisting that wifi on FreeBSD is just fine, and that development priorities should be elsewhere).

I would point you at the FreeBSD project and the folks that have developed it, are developing it and will develop it. Some are making a living at it, others it's a hobby, others are in between.

Programming is a skill, a lot has to do with learning a language, but the art has always been in designing and understanding that it's the overall system that matters.
FreeBSD is not that big. Just browse around the Foundation's web site... https://freebsdfoundation.org/ ... The Foundation has to prioritize between development, decision making, and coordination of effort. Yes, the developers who contribute to FreeBSD have fantastic skills. But they are also real people who have to prioritize their time and efforts between day jobs, making contributions to FreeBSD (in form of code, decision making, and the like), and other commitments. Who's gonna sponsor THEM?

Being able to write code and getting a helloworld running (creating something that you can use/enjoy) is one thing. But being able to write code that is useful to a crowd of people - that's different. Many people can write code, but few can come up with useful code. Just because I (after some difficulty) wrote a code snippet in sh to list all packages installed on FreeBSD, that doesn't mean that it will be useful to a large portion of FreeBSD users. We don't have a crowd of ppl like vermaden , who frankly wrote a lot of the code behind boot environments. Most of us would have no idea what a Boot Environment even is. If you have an idea, then you're closer to being the wunderkind like Michelangelo was.
 
Good programmers are more craftsmen than artists. Almost anyone can become very good at their craft but not every has an artistic talent. Even within the constraints of time and deliverables you can strive to be a better craftsman. The organization for which you work may/may not care about the quality of work but you should. Do it right and you don't have to waste time in future fixing bugs. Do it right and do it fast to be given bigger responsibilities. To improve on your craft take every opportunity to learn from better programmers (this is true in pretty much every field -- learn from the best). You also need to find a way to push aside all the distractions and focus on your craft. This is much harder now but there are no shortcuts.
 
Languages except C or C++ don't make it in general. I find C++ complex , also the porters handbook. Like it's written for knowledgeable persons.
Not only do you need a good knowdlege of shell-scripts, C , make, but also the FreeBSD tooling.
That's exactly the same as with everything else in life, you start without any experience and slowly (and painfully) gain it; I hope you don't think someone was born knowing all that voodoo needed for porting? ;)
 
You are never "too stupid" ;-)
When I started with FreeBSD 5.2, I was happy when I could install the system at all.
I was interested in it and learned. My mentor at that time was miwi. Long before I joined the FreeBSD team he showed me a lot of things. It was small steps. Even today I always have to ask other developers, because you can not know everything.
But you are never "too stupid". You just have to want it ;-)
 
I kept the whole time your last sentence in mind. Your are right, it is disrespectful, like slang or worse.
There's levels and levels of understanding and deciding what information is important and why.

Yeah, it does turn me off when people use buzzwords without any substance behind them. But sometimes, you do need precise terminology to describe behavior or expectations one has of a group of people. Can you define terms like 'Sanctimonious', 'Hypocritical', 'Demagogue' and the like correctly, on the fly, with same ease as 'server', 'daemon', 'permissions' or 'connection' ?

Among people who are actually comfortable with FreeBSD/Linux/etc (like us), there's a common 'language', and a 'culture'. As in, technical terminology and certain expectations, like calling our own shots to solve problems. We do seem to think that every problem looks like something that can be solved with a computer, coordination with other fields of expertise be damned.
 
This was one of the items discussed in the May 2023 Developer Summit. They brought up the fact that developers and users tend to congregate in different spaces, and the core team would like to see more crossover.

It's unclear to me why devs and users tend to be in separate places. Is it simply mechanics, where developers prefer mailing lists and users prefer forums? In that case, we simply need to provide a place that is attractive / accessible to both groups. On the other hand, it's possible that developers and users just prefer to be separate from one another, considering the bulk of the other group's communication "noise".

I am in both groups, at least in terms of interest. I am not a FreeBSD developer, but I am very interested in the development. Which means that I get to try to track forum, lists (of which there are over 100), bugs.freebsd.org, reviews.freebsd.org, IRC (multiple channels across multiple servers), and discord. It's a lot.
 
... it's possible that developers and users just prefer to be separate from one another, considering the bulk of the other group's communication "noise".
Or worse, they consider it offensive.

Think of a user who thinks that a malfunction at their user interface is the most important problem in the universe. We see plenty of these issues being discussed here on the user forum: "When I try to pair my headphones using Bluetooth, the background color of my clock window changes." Now think of a developer, who is thinking about "Can I make the function in the VFS layer that ref-counts the open file handles do so without copying the file descriptor, to prevent bugs and run faster." Those two people really have no basis for communication. Matter-of-fact, they probably think the other's focus on their particular issue to be a total waste of time.

Obviously, for clarity (and comic relief) I used extreme examples.
 
I find the forums to be a fairly good compromise. Can be quite technical but still user-focused.

The mailing lists (or at least most groups) are on the technical side whereas things like Reddit are even further onto the user side.

A fun side effect of FreeBSD being monolithic is that these forums tend to take much more grunt than all the many different distros. In terms of daily throughput I predict it is beaten only by Ubuntu and the Raspberry Pi forums.
 
Back
Top