snapdaddy

How many editors can you think of that don't do any (strictly) unnecessary file operations, e.g. renaming files? The author's problem is that Emacs is just really good at it, so he wants to use it more.

I feel like this is a wild mis-characterisation. American isn't in danger of becoming a victim; America is trying to suppress academic pursuits and intellectualism. It is politically inconvenient, which means it needs to be eradicated.

to come up with and advocate for paired programming before the concept existed _is_ pretty brilliant. And you also don't understand how much those practices improved software engineering, presumably because when you started programming they were already entrenched ideas, and so all you see are their shortcomings.

Those ideas do have flaws, and most of us are looking to improve how we right code. So if you aren't blind to those flaws, please, write a book or a blog or whatever on the best ways to write software so that we can all learn.

I was completely ready to agree with you, but the code that I browsed actually looked really good.

https://github.com/unclebob/fitnesse/blob/master/src/fitness...

Yup, OK, got it. The FitnessContext looks a bit rough, but no big deal.

https://github.com/unclebob/fitnesse/blob/master/src/fitness...

That's completely readable, I get it.

https://github.com/unclebob/fitnesse/blob/master/src/fitness...

Again, looks fine.

The main issue with all of these files is that there is quite a bit of boilerplate code, but that's Java's fault, not the code's fault.

I'm sorry, but I disagree. Looking for the most substantial pieces of code that I could find, and they look really good. I'm sure there are some little utils or something that look strange out of context, but I would be thrilled if I were called to work on legacy code and it was this nice.

Yo! What's wrong with chess?

;-)

FWIW (not a lot), I do believe in a lot of these principles.

For example, even with widescreen monitors, it is still useful to limit line length. Why? Because many people will have multiple source files side-by-side on one of those widescreen monitors, at which point it makes sense for them to not run on indefinitely.

And of course, that is just a guideline, one that I break regularly. However, if it's a method with many args, I'll break the args onto their own lines.

However, the overriding concern is that an organisation works to code towards a common style, whatever that may be, so that unfamiliar code is predictable and understandable.

It would be good if we could create a digital fortress around the US that stopped unwanted things from coming in. Like a firewall for the country.

. . .

As a senior developer of 30+ years experience, I agree and was going to post the same thing.

If code is difficult to understand, I consider that to be a bug. And if, for some reason, the section of code actually is difficult to implement, I would at least want a pretty good comment explaining the context around it and the reasons for the approach taken.

Not only will this help improve the code, but if it is a senior developer, it will help them to understand where they've become blind to a particular complexity. It is great feedback to have someone explain that they don't understand code that seems 'fine' to you.

That's a really interesting data point about your experience with TypeScript. I'm going to have to file that away as something that I'm not sure what to do with right now, but also as an interesting thought to keep in mind going forwards.

I acknowledge that there are passionate users of most programming languages, but I also 100% agree that the FP crowd are something different. I feel like most other languages have some nuance at least; if you're writing transpilers or kernel modules then hell yes, Rust makes sense. If, however, you are trying to churn out a web-based store-front, maybe don't look towards Rust.

But with FP, it seems like it is always the answer. And it's even better if your Operating System can be immutable too. And your build scripts. And, even if it take 10 times as long to write, at least we will be confident that it's type safe at the end.

As others have commented, most people have specialised knowledge. For example, I've been programming professionally for about 30 years; let me share my knowledge of game programming:

Most people use Unity these days. I'm pretty sure it's in C#, and there was something about the licence recently that they probably backed down from. You can still write in c with OpenGL, but you will probably have to create your own game engine(?). You will need a game loop where you track the milliseconds elapsed each frame. Try not to stutter in your game loop. 16 ms. Oh, and double-buffering the output is probably a good idea.

See? Don't sound so smart now, do I?

The opposite viewpoint is that you are being included in these meetings so that you can prevent bad decisions by management. What if you aren't in a meeting where it is decided that you should implement feature x because they imagine it to be low cost, not realising the complexity?

I agree completely. I tend to do 'UML light', where I don't worry about the finer details (e.g. marking fields public or private). The best solution is one where I can sketch out the outlines of a class and have some tool automatically generate UML which I can then edit.

And C4 diagrams are great for explaining software architecture, which wouldn't have been possible without UML and esp. class diagrams.

I don't think it was software architecture, UML or design patterns that was bad. I think the 'Open-Closed Principle' is one of the worst ideas to ever gain popular acceptance.

For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification.

However, you could also rephrase that principle to be: 'you should always prematurely abstract your designs'.

I think if abstraction was viewed as a negative to be avoided unless necessary, software architecture would have been far better off.

To be fair, premature abstraction is a lot of fun for those that do it. It's just those that follow who aren't so keen.

I will treat your comment as serious and explain why I personally use emacs.

The thing I love most about emacs is that it is joyously consistent. The same key combination to jump ahead by a word works everywhere, such as when you're opening files or navigating directories. This consistency means that I am often very efficient trying new packages that I have never used.

Maybe you've never seen someone use emacs in anger? If so, check out this video of Steve Yegge doing some stuff in Emacs: https://youtu.be/lkIicfzPBys?t=142

If you were asked to provide guidance for companies who wished to avoid using nicespeak, what recommendations would you provide? And do you have advice for situations where a company might want to emphasise/de-emphasise aspects of the truth to market itself?

As an emacs user, I support this comment. I think the main point is that there is a long-term benefit to learning multi-use text editors. Yes, it is painful at first, but the dividends are repaid over time.

As for VI vs emacs - both are good. I would search YouTube for 'Top 10 VIM plugins' and 'Top 10 emacs packages' and see if either grab your attention and go with that.

Hey Cole,

I think the site looks great and is very useful. The one suggestion I have would be to add a bit of space to everything to give it some breathing room.

These are the changes I made: try them out and see what you think.

body { padding: 10px; background: #f0f0f0; }

#groups { grid-template-columns: repeat(auto-fill, minmax(350px, 1fr)); }

.group { padding: 10px; margin: 4px; }

.group > span { margin: 0 20px 20px 0; }

.gmatch { padding: 6px 0; }

I've been programming for approximately 20 years, and there was a period where I was definitely burnt out. I can remember thinking to myself, 'who would ever read a blog about programming outside of their work?' But, that passed and I have been in love with programming again for a long time.

My advice would be to do what you need to do to weather this period of your employment and not give yourself a hard time about it. you don't NEED to be doing anything. If your job is still coding, do some coding while you are at work, go home and then do some hobby that you have been wanting to do. Learn to play the piano or fly racing drones or whatever.

If you have a long enough career, having a six to eight month slump of not being into coding is nothing, so don't sweat it. Just make try to make it through it without making it worse.

Yeah, this description doesn't sit with me very well, either. I fully support the argument that Angular is not a good choice because React is more popular and has a larger pool of developers, but not that it is more complex.

I too would like to hear about what complexities you are encountering and if they are incidental or necessary complexities.

I feel like I am the odd one out in that I don't hate MBTI. I would not use them as a measurement of performance or individual worth, but I do think they might have some value as a team-building exercise.

Imagine everyone on a team does a (free, found online, not 'legitimate') test and then spends an hour or two discussing the results. Everyone learns that the developers are not very agreeable (joking! Lighten up!) and that the sales people are extroverted and that we're all quite different but we can all work together to achieve a common goal, or whatever.

I think it's fine so long as you don't claim it it science and that you don't get caught up in it. And it's better than going on a ropes course . . .

The first time I tried this simulator, it looked like this: https://www.youtube.com/watch?v=CtrB5sQtrvA

Of course, that was not on an RTX 3090.

I disagree with nearly every response in this thread (not yours). The 'cutesy' error messages are step 1 to providing a better user experience.

'This is awkward! Something went wrong and it's probably our fault :-('

is much better for users than

'Unexpected error occurred in logTicketResponse'

And no, it isn't sufficient, but it is better. Providing useful error messages is really hard (and it sounds like your application does a good job of it), and we as software developers are not very good at it.

For everyone who complains about the cutesy error messages, how much time are you spending in your own code to provide useful error messages that explain the problem and suggest resolutions?

My recollection of the time was that it was the port of Microsoft Office that made Apple viable as an alternative operating system (which was a result of the DOJ pressure, and not because Bill Gates was feeling charitable). Without office compatibility, you were locked out of all business communications.

Looking at the page code, it appears that their main 'secret' is pre-loading the images for the page that are one-level deeper.

I agree that dependency graphs are the way to go - they show the structure of the code better than anything else. And yes, the problem is that the graphs show all of the details, whether they are important for gaining a good, overall picture of the system or not.

What you need is the ability to filter the graph. Narwhal and the nx mono-repo toolset has a pretty cool dependency graph feature built in. Here's a video of how they use it:

https://youtu.be/KTGKpoiLE0k?t=253

Have you tried using k3s? How do the two compare?

People in the comments are so quick to be snarky, but this is all really good advice.

The reason for choosing monolithic architecture is simple: velocity. You need to move fast and be nimble until you are able to find a product that people want and/or need to use.

The people who (at least initially) advocated for microservices were the first to point out that it is better to start as a monolith and then refactor into microservices as required by external factors.

Yeah, as I thought - If I were the maintainer of that project I would have had no issue with her merging that. But I also understand why PRs exist and process, so I would have said, 'yeah, cool, just don't do it again. Nothing to see here, move along.'