HN user

apabepa

156 karma
Posts0
Comments29
View on HN
No posts found.

For me it is difficult to give good code comments just when code is written. The problem is solved, the tricky parts if any are internalized. I dont mind reading code so just documenting what the code is doing does seldom bring value. The important thing is to document why the code does things in an non obvious way and unintuitive scenarios and edge cases etc.

When revisiting code is the best time to add comments because then you will find out what is tricky and what is obvious.

Code reviews are also good for adding code comments. If the people reviewing are doing their job and are actually trying to understand the code then it is a good time to get feedback where to add comments.

Please don't. It will just become the usual Americanized trope filled insult to the original story. Stick with Marvel to produce your generic entertainment.

Minimalist as in the README does not specify that it refers to the UI though.. If I read minimalist software I would assume a more holistic interpretation unless otherwise specified.

Maybe replace minimalist with modern for a more correct description of software with 100s of dependencies? (Joke!)

Nitpicking aside, The app looks good and I do like this TUI trend!

This is a rather pretentious take. Not sure I agree that a lowest-common-denominator i.e. violence and sex TV-drama counts as common culture. The setting could be whatever, it would still sell using the same tropes. I guess it is in a way similar to how McDonald is European "common food culture"..

Functorio 5 years ago

I have been day dreaming about a program taking a factorio blueprint and running it through a genetic algorithm to produce a compressed but still functional version. I can imagine it could produce some interesting spaghetti layout! One way to ensure that the end result still works the same would be to only let the algorithm work with a selection of predefined refactoring steps that guarantee that the factory does not break. Another maybe more interesting approach would be to include some actual simulation that could test the factory. With the simulation the algorithm could work more freely with possibly destructive changes and apply them until the factory works as expected. This I figure would produce even more interesting spaghetti..

A more natural way would be to arrange for people to work together in smaller groups on tasks as part of the normal work. If you provide this then I agree with the parent poster if there is a social interaction to be had it will come. If not that's OK as long as we can work together in reasonable harmony. I value professionalism, if I can make a friend through work that is great but it should not be the norm that we all have to be friends to get along.

Thanks for the response, very informative, I feel it explains a lot of what I was confused about.

So maybe a simplified view for me is: massive adoption of JS + frameworks, cookie cutter development, no point learning anything else when you have the golden hammer.

I actually thought you still did learn HTML and stuff before the digging into the frameworks. But maybe it is analogous to learning assembler before python, i.e out of fashion and not needed to get the job done.

In this context what seems like the simpler and more suitable solution to me (static HTML+some minimal JS) might not be on the map for most modern web developers. What they do is overkill but it is what they know and it gets the job done.

Yes the ads/trackers/etc is most likely a reason that a webpage cannot be completely without javascript.

Two other possible reasons from the top of my head:

If a web developer is hired to make a site they can probably charge more if it is a fancy javascript site. In some cases it might be in their self interest to up-sell this to a client that does not know better.

If a web developer makes a site for themselves I am sure many want to take the opportunity to get some experience in the latest web-tech while they are at it. Just as I will use an obscure programming language for my next side project..

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more likely I just don't understand the allure as an clueless user.. I am almost tempted to make a webpage to see what the big fuss is about!

I see this as a part of the trend towards a bleak future of auto generated low quality generic content flooding the web. It already feels like it has been going on for a long time even though it has not been fully AI-driven before. This is a natural evolution of the direction things are going towards. I believe that non-algorithmic curation and aggregation will become even more important services that people will be willing to pay for.

Another way to do it is to fix bugs and refactor old not so good code. Force yourself to understand the actual underlying logic and the problems it solve. Use your frustration to figure out a better design that code so it wont punish future programmers.. After doing this for years you will hopefully have built a good habit of simple and clean design.

Okay, was it a bad game? Who knows, hardly anyone played it. That's the crux of what he's saying.

I played it a few times when it came out. I had been looking forward to it. Unfortunately it was unbalanced with very obvious exploits. Maybe they fixed it later but I gave up on it.

Yes I agree for the general case and I have seen this problem many times where management refuse to see the problem with anti-social loners holding too much of the competence in a team.

It can also depends on what kind of software you are working on. Some parts might require a 'brilliant mind' to push through a spike solution for certain areas. This individual should not really be in a "normal-happy-scrum-team" though, that would be a punishment both for the team and the individual...

I agree with this comment. I see it as pragmatic thinking not to test people at this point. It is a special situation, if you show any symptom of sickness just stay at home, it should be a no-brainer. What if you cough in public? Will you shout "IT IS JUST A COMMON COLD" and people will feel safe? Actually people who "just have a bit of a cold" should stay at home in normal circumstances too in my opinion. It might be OK for you to have a runny nose but some other poor guy might catch your cold and get it worse because of bad immune system. Its comes down to individualistic vs collectivist thinking and now might be the time to think about the greater good.

What does modern mean in this context? I see this word being used a as a positive adjective a lot recently to describe rewrites etc but it is unclear to me what it actually implies

I share this sentiment. I tend to categorize cruft code in two different categories, and in most cases I have encounter both stem mostly from programmer inability rather than time constraints.

The first kind is what I would presume is the most normal one. It undoubtedly shows up if you have unregulated feature growth in a codebase with low feeling of code ownership. Grunt programmers, or drive-by feature development teams shoehorn in new code to fulfill their requirement. This leads to to the normal degenerate codebase, modules are thousands of lines long, functions are hundred of lines of deep staircase like if-statement logic, spaghetti dependencies, promiscuous state-sharing etc. The classic ball of mud.

The second kind of cruft is the one where someone tried to be clever above their ability and created heavy abstractions that are ill fit for the problem at hand. Signs of this are over-usage of complicated language constructs like inheritance, meta-classes, runtime inspection etc. The style can lead to verbose, boilerplate heavy code that overshadow the business logic. I tend in my frustration to call this abstraction wankery.

In the ball of mud-pattern the programmers often lack the ability to properly form the abstractions needed to sort out the mess and they are aware of that, resigning themselves to do trying to fulfill their task at hand without breaking the existing fragile mess. The grunt might be well knowledable in the buisniess domain and has programming as a side skill. The drive-by coder does not have the motivation to understand the whole messy codebase and does the minimal change and tries not to break anything in the process.

The abstraction wankery is driven by other things. Usually a seconds systems effect. The Junior programmer has some code under his belt and is trying to level up his skills, a smooth talking architect with low insight in the business domain is cargo culting some new fad, etc. This kind of style is usually well perceived by management, they hear the buzzwords and it sounds good in their ears. It can take some time until the card house falls, usually a requirement comes that does not fit the abstraction and unexpectedly take exorbitant amount of time to implement, or maybe a deep rooted bug that requires fixes that ripples through the whole codebase.

When the cleaners are finally sent in the big ball of mud can usually be shaped up by incrementally applying the standard refactoring techniques until structure starts to show. The abstraction mess can be much more difficult too clean up. Incremental improvements can be more difficult and sometimes a rewrite of the code is required, leading to a much more noticeable lack of feature velocity than the ball of mud fix.

I recall hearing/reading that a lot of the time in the office is passive/suboptimal. The productivity gain is that you have the people there in standby. The gain is that the important work that do happen is not blocked by people being off work since you can pull them in instantly compared to "Only Bob knows X and he left for the day, lets schedule a meeting tomorrow"

I am not sure what you mean with production-ready here.

Erlang has certainly been used in production, not only Whatsapp but also have a lot of production systems in telecom where requirements on up-times etc are pretty high.

If you mean that there are no ready made off-the-shelf standard way to handle runtime configuration and deployment I guess it is because the big telcom products usually roll their own per product so it haven't made it into the OTP backlog.

Its good advice but I wouldn't spill my guts to someone taking notes. I would try a more casual approach, talk with people over a coffee or similar