Hacker News new | ask | show | jobs
by axegon_ 2108 days ago
1. Simplify - as a rule of thumb, if something looks too complicated it probably is. If you think there are too much "ifs" in the code, there certainly are.

2. Remove any "shiny-new-toy". A perfect example would be my bank, which operates in ~15-20 countries: Their interface isn't a shiny web interface with pretty animations to cover up a slow response time. The interface all employees use is built with ncurses. That speaks volumes.

3. Profiling the code and by doing so find unnecessary bottlenecks.

4. Never blindly reinvent the wheel. If a solution looks absurd but is highly used, chances are the solution is there to cover an edge case. Ask before you decide to "fix" it.

1 comments

i feel like there is an appropriate middle ground somewhere between "shiny-new-toy" and ncurses...
It's probably a 15+ year old application, which, if it was web-based, would be built on 2-3 out-of-date webstacks, badly joined together, with who knows how many security flaws.

Compared to maintaining that, ncurses doesn't sound too bad.

True.

I used to provide dev teams with cli tools (testing, infrastructure debugging, etc.). They used them from time to time but only after implementing basic gui with tkinter or simple html/js/css they started to use them more often. I prefer terminal more than gui but if you don't use terminal 90% of the time it's much easier to click the button on a website.

You are right - that's ncursesw ;)
Hypothetically... Late 90's web, which wasn't bloated with 150mb javascript files which run your CPU at 10000000%...