IF LIVES DEPEND ON A SYSTEM

1. Code review, collaboration, and knowledge sharing (each hour of code review saves 33 hours of maintenance)

2. TDD (40% — 80% reduction in production bug density)

3. Daily continuous integration (large code merges are a major source of bugs)

4. Minimize developer interruptions (an interrupted task takes twice as long and contains twice as many defects)

5. Linting (catches many typo and undefined variable bugs that static types could catch, as well as a host of stylistic issues that correlate with bug creation, such as accidentally assigning when you meant to compare)

6. Reduce complexity & improve modularity  -- complex code is harder to understand, test, and maintain

-Eric Elliott

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. ☹

Definitely a blackboard or whiteboard. Definitely helps in the modularity of my code. I love it when I spend 90% of my time drawing out my idea on a blackboard, implementing it and having it be super modular.

Not exactly dev stuff, but LaTeX low-key makes me nervous.

In writing my thesis it seems that through some keyboard-fuckery I managed to slip in some weird unicode bullshit character somewhere, so that it doesn't compile. Alright, I just do \DeclareUnicodeCharacter{0301}{ASDF} so that it gets replaced by ASDF. Searching for ASDF in the output pdf file does not yield results, so I can't even find the location of the fuckery in the text. It seems that unicode character is somewhere in my .bib-file and I guess my citation style doesn't even render the part of the data that character is in after all. So the above hack works, but still there is some weird-ass character in my bibliography file that I can't find.

On another note: I get that modularity is cool and all, but who thought that it is a good idea to give people zero transparency over what macro stems from which included package? No namespaces etc. I end up including a whole lot of packages that are needed for exactly one macro. That bloats up the file and you have no way to trace back which macro came from which of the quazillion included packages.

...then again maybe I'm just a lazy piece of shit whose google searches end before success and all of the above has some easy fix.

For the coming few months, refactoring my entire life. Everything will be redone with modularity in mind. So far it seems to be working well. Once the foundations are stable, I could start focusing further on the development of my Linux distribution. Hopefully that'll be done soon.

It’s so great to hear Apple is finally officially making the transition to rolling out their own silicon on everything... fucken fabulous. Sure there may be problems at first but this might just get the ball rolling to get more companies todo the same... we need to eliminate the silicon monopolies... ARM and rolling your own is the future... well it always use to be the standard... back in the day, until the whole modularity and lean manufacturing and order off the shelf shit came about .... but finally we have once again come full circle back to where things use to be.... pairing hardware with software fucken beautiful LOVE IT!!!

Sure this will affect portability but .... guess what folks... means more jobs for us... quit being lazy and complaining about having to work..

Love vertical integration!!!!

You know what's fucking horrible?

Implementing new features to an Android app in production that another dev wrote...

...which has no architecture, no documentation, no modularity, no testability, everything runs on the UI thread, filled with spaghetti code and it somehow works smoothely so I have to not fuck it up.

Oh and I'm also a junior. So fuck me, right?

My co-worker had to add some small feature, and while at it, he thought it’s a good idea to “refactor” the entire repo.

Now the code is over-modularized and full of disconnected 100 line files, just for the sake of modularity.

Sometimes less is more

i'm starting to REALLY REALLY REALLY appreciate modularity

the gnufather has blessed me

1. Learn to be meticulous.
1. Learn to anticipate and prepare a functionality up to 90% accuracy and coding it in a one shot.
1. Become advanced in SQL.
1. Increase my modularity abstraction awareness.
1. Learn to TDD properly.
1. Don‘t get angry with my kids but explain to them with papa is always right in a Calm voice.
1. Do the same for partner.
1. Train my speed running in case partner wants to bash me.
1. Become advance d in Java.
1. Learn to write a bot.
1. Learn more about servers and hack at least one thing even if its a wifi.
1. Install kali linux.
1. Make myself a custom pc.
1. Ask god (or buddha if god is too busy) to make days longer.
1. Buy a vaporiser ao i can smoke my weed without mixing it to tobacco.
1. Get my license.
1. Start investing.
1.........

Pet peeve: the claim that static typing prevents errors.

Today I worked on a C# project that's a mess of nulls, side-effects, inferences, and race conditions. Then I went back to a JS project that's twice the size but written in a clean, well-tested, FP style and currently has fewer than 10 issues logged.

Look, I get that there are upsides to static typing, and I'm open to introducing typescript or flow for our JS code.

I just can't stand the faux-concern from the static typing dingleberries when they are the ones who produce these horrendous lumps of unmaintainable shit, and the JS/Python/Ruby/etc people are over here quietly reinventing functional programming and code modularity.

A framework based on socket.io, for better code organization and modularity

If I could, I'd attempt to create an ideal language. I'd aspire that its features would be:

-The easyiness of Python

-The library ecosystem of Javascript

-The readability and cross- platformness of Java

-Functional features of Haskell

-Modularity of Lisp

-Low level features of C/C++

-Powerful with strings and data, like Perl

-Both compiled and interpreted, with REPL

Anything missing from your favorite languages?

I prefer it doing 2 tasks parallely during the initial phase of requirement gathering and design phase.(makes more sense if you are working extremely new system and framework)
1. Keep collecting requirements from clients and understand them.
2. Collect different designing aspects for the project and parallely, build a POC for 2 purpose: to get hands into the new Framework and also as a demo to clients. Working on POC helps in 3 ways: Improving understanding of requirement, improving framework knowledge, and playing around with code whenever bored of designing and reading tons of existing designs..
3. Once primary requirements are clear and fixed, analyse all different designs, if possible I setup meetings with senior devs, principal engineers (they help a lot when it comes to reviews on scalability and reliability of a design)
4. The above design is mostly architectural level. Once design is fixed, then I start taking each component and prepare a detailed implementation design. (Notice that whenever I am bored of designing, I spend sometime in building POC)
5. In detail design, I focus on modularity and flexibility. Anything defined should have getters and setters for example. This will help you reuse your code. Keep the interface between components in your design as generic as possible, so that in case your MySQL is change to Postgre or NoSQL, your design should be able to adapt new features..
6. Instead of building entire project, define feature targets and deliver small features.. this will help you to be in line with the requirements with minimum deviation.

Play designer board games; they are multi-tenant programs, complex algorithms, modularity, meticulously balanced, and all elegantly linked to an artful UI. They are also made out of cardboard.

It is hard to play them and not become a developer that builds increasingly holistically.

Joined a new company as front end developer after working for a legal tech for 3 years. The codebase is shit here. There is this ReactJS developer who has done everything except for following standard code practices. No modularity, no reusable components. Some files go beyond 2000 lines of codes. It is a literal nightmare.

The worst part is, he does not understand that he has written the worst code. I dunno how to handle this now.

so i did this nice tool with data structures, dynamic ui composing, input sanitizing, modularity and scalability with tidy and efficient javascript and useful css.

showing it to my boss: "cool what you can do with html". WAT?

(he is not a programmer but knows i´m into web-programming)

Is it fine to manage React states on your own ( kinda lifting up the state way ) in a medium size application? I've built 70% of the application without a lot of trouble. The only problem is there's no way to pass states to the sibling components without lifting up the state and lifting up the states decreases the modularity of the code. A lot of functions (handlers) have to be re-written in different components.

Would I be better off using Redux, etc. Thoughts?

I really don't know how I feel about SystemD.

Their recent reveal of Systemd-Homed made me once again doubt the logic behind the project. I mean, yes, systemd is handy to work with at some occasions (SysVInit, for example, doesn't store information about when a certain service failed), but SystemD is slowly eating up more and more of the system's jobs, and I'm a little worried, what would happen if SystemD suddenly went bust.

That will never happen, I know, but... Wasn't the idea behind Unix... Its modularity? That its made up of clearly defined parts that cooperate with each other, rather than a huge, monolithic projects that handle several functions at once?

This is not meant to be a hate post about Systemd, just a little... reminiscence about its goal and role in the Linux community.

Any ideas are appreciated! Discussions are welcome. Just... keep it civil. Please.

(insight: for organisational and modularity purposes we tend to cut each object (which are usually chemical reactors or unitary a operations for plants ) into classes and subclasses and such, also to provide a common guided framework to insert a new objext to expand our simulation program).

Me: should we just use a middle parent class for these objects or leave them like this. Also I believe we could do X the Y way instead of X but requires updating the user guide. I could do that as well though. Up to you.

Professor: Yes *too bad it does not comply expected answers* Also mmh can you provide me a paper for tommorow morning to explain our project and why it should be better than what other universities do need to show some friends

Me: *looks at the watch, it's 9 pm, reflects upon the fact he has to get 2 hours of travel to even get home* well it's a bit hard for tomorrow morning, can you leave me 2 days?

I rise my head and realised my professor took his things and went home in that split second of me checking the time.

every (cl)ass has reference of every other class and people are talking about modularity and encapsulation.#FML

- Fault Tolerance!!
- Adaptability
- Modularity!!!

a little later for wk131 but:

To build a completely open platform for everything we have right now... operating systems, manufacturing etc...

The basic idea being serving a line of products under the platform's branding with an algorithm to control which open source implementation of the underlying architecture is most stable/efficient and keep switching them out. This is incredibly ambitious.

A reward based system to power this based on contributions. Example: if the open platform oled manufacturing industry uses a manufacturing process you came up with ... You get paid until well another person's process is better and it gets switched out.

Ideal modularity tbh.

Switching out parts of apps .For example : if the most efficient map algorithm is created by X it will be used. Payments split up as better forked implementations appear.

It's a thriving fun environment. Fuck job stability. Humans weren't meant to live like that. Hunt an animal today or you won't get food tomorrow.

On the plus side this will close the intellectual gap in the current generation.

Radeon graphics driver crashed again.

I hope one day they will actually fix it but the light of my hope grows dimmer every day.

Hire some talent?
Rewrite their code in Rust?
Do some static code analysis?
Better modularity?
Some code reviews? Proofreading?

I am at a loss of words. The crashes need to stop.

It makes me want to cry in frustration that I... actually love SystemD, as an *init* system. But with all the crap it brings along with that core part, it just makes it so much harder for me to really enjoy! Why can't it be modular? Why can't it be broken down into independently-installable packages, with the init system as a core? Is there some sort of internal API issue? Or does mister Pottering just does not want that to happen? The Linux world has always stayed by the idea of "1 package = 1 task", and it made the system management so much easier!

But now... When I switch to SystemD from SysVInit, I get... What SysVInit did + so much more I didn't ask for... I just... Don't understand it.

What would be the easiest way to make line 16 work.

I don't know if there is a simple way to tell this "if" argument to check all af the "Remote Host" classes for a matching string at that index.

I'm trying to design with modularity in mind.