morbidhawk

I'm in the process of moving all of my repositories hosted on GitHub to fossil scm instead. Unlike GitHub it is open source[1] and with a simple cgi script[2] I am able to host all of my repositories on my own web server. After knowing git, fossil wasn't very hard to learn and it comes with ticketing and wiki built-in and accessible via a web UI locally on any machine I'm using.

One of the benefits in addition to being able to read fossil source code and being able change/style the web interface however I want is that I don't have to worry about staying up to date on Terms of Service changes I really have no say in.

Edit: failed to mention fossil can import/export to/from a git repository[3]

[1] 2-clause BSD license: https://www.fossil-scm.org/xfer/artifact/f99187d1905883d3

[2] cgi script: http://fossil-scm.org/xfer/doc/trunk/www/server.wiki#cgi

[3] import/export git: http://fossil-scm.org/xfer/doc/trunk/www/inout.wiki

> The interviewer can reject you because "They had a bad day"

The only answer in your Quora link that has a lot of upvotes is by the author of CTCI and she is saying just the opposite, and instead of blaming the interviewer she is putting all of the blame on the person being interviewed. I find this quite disturbing, and you are right there isn't accountability on the interviewer, here are the things the author of CTCI is saying:

> Maybe you came off as arrogant

> A number of different things could happen. But when someone asks this question -- why did I get rejected even after doing well -- the problem is nearly always in the second part: You didn't do well

> If you were interviewing with a big tech company, they have basically infinite programming spots. They don't reject someone because they found someone better; they just hire both.

> So despite what you think about your performance, you probably didn't show good algorithmic problem-solving skills

I'm all for self-introspection to assist in self-improvement but her persistence in ignoring the fact that interviewers are fallible is troubling, she is the go-to resource for probably most interviewees and interviewers and I don't like that she assumes that the thing that went wrong is "almost always" the fault of the interviewee. It's some grade-A BS.

> code comments document the why, not the how

While I do agree with this since thoroughly reading the code itself tells you the how I find comments that tell me what it does to be just as helpful as telling why it does it.

I used to fall into the self-documenting code camp back when I programmed in Objective-C and long descriptive names with named parameters made it read like English but as I've read more code in more languages I actually prefer shorter names supported with code comments that tell me clearly in English what the code does.

For instance earlier today I was reading some of the source code in fossil-scm in the check-in.c file. In it there was a function that was simply named `locate_unmanaged_files`. If there wasn't a detailed comment preceding that function I would have assumed it merely found the files and reported on them directly but after reading the comment explaining what it did I realized it stores the files in a temporary SQLite table, after reading that I learned that "locate" had a wider meaning then to just find it and return it but it rather meant that it is now located for any part of the system to find in the database. It would have taken careful reading of the code to have realized this and it helped me to better focus and understand the code I was reading.

I've always lost motivation sometime shortly after starting on a new side project.So what I've done lately is when I think of something I'll then determine if there is a way to get it built and usable by the end of the day, even if it is just a simple script. This way I can actually later use the thing and when I have another idea to expand on it I can take that on later as another day's work.

This might not work for everyone but for me I've actually built a few useful tools that I use everyday and have been able to continue building on. The only 2 requirements needed before I undertake something is 1) that it is something I see myself using on a semi-daily basis and 2) that I can build it within a day.

> It's astonishing how often this gets reinvented

Wow, I'd only heard of libgit2 before. I can't believe how many git-related python packages there are. Yes git isn't a library, it's a program like you said, good catch

> I never start anything from scratch, as I have about a dozen application skeletons ready for various specific purposes, plus similar libraries I wrote, plus a knowledge of several large commercial SDKs, and developer experience in several major FOSS applications

I've had a project manager (very insightful guy) tell me something similar before. He said "as you get more experienced you'll (ideally) write less code and instead reuse code from libraries you've written in the past". I've always wondered how that works for someone? I'm assuming certain projects will have requirements where specific technologies would be used in the front-end and persistent layers depending on the kind of project you are building and so those wouldn't be as reusable but perhaps algorithms you've written before might be reusable on the computational side of things. Like perhaps if you had a library that handles very advanced moving cost calculations you could ideally use that same library in different software forms (mobile, web, desktop, command-line).

Edit: Git might be a good example of a library that can be reused a lot and used within many kinds of applications (IE: inside web app, within IDE, from command-line, desktop app, etc)

This looks like a very feasible approach, I didn't realize you could lock scrolling for side-by-side buffers. That's really awesome. I'll have to give this a try

I have the same exact problem, most of my teammates that review my code either obsess about variable names or code that wasn't done the same way they would have written it. It's like my code is being skimmed to bikeshed about it and not really read through to find behavioral, logic, or architectural issues. As I am the dev w/ the least amount of experience on the team I feel at a loss and I end up re-writing code all the time for issues that many times aren't actual logic errors. The most frustrating thing is a lot of the "different" ways I've written code is inspired by code I've been reading from some of the open source frameworks I use, and I've picked up on some patterns that might not be mainstream Clean Coder appropriate but effectively solve problems.

I've realized that I personally value code that works properly a lot more than any style/standard issues. I've tried to be very thorough in my own code reviews, reading it in its entirety and pointing out areas that look like actual causes for concern in terms of how the code behaves in hopes they'll do the same for me.

> Name suggests boolean but type does not

I've seen something similar with xUnit in C# where an Assert statement returns a value. `var single = Assert.Single(collection);` It does the assertion and returns the single item in the collection, which is awkward, but also familiar (from Linq's Single) and convenient. Here there are tradeoffs and I could care less about the dogmatic "never do this" complainers. This might break the 'Principle of Least Astonishment' the first time you see it, but after seeing it once it makes sense and is no longer surprising.

Additionally, in the case of this criteria, where there is a boolean-looking function that doesn't return boolean, it can often be quickly assumed that something more than just a boolean needed to be returned.

This also reminds of command-query separation which makes a lot of sense to follow in most cases ('get' shouldn't change state and state changing methods like 'save' shouldn't return a value). But there are going to be exceptions to this rule and there are scenarios where no matter if you return data or not you might need to know the HTTP status code, etc. Grabbing code and doing dogmatic research on it doesn't make a whole lot of sense unless a developer who really knows the code well can justify themselves and discuss the why.

In addition to scope, I think language syntax plays a role and naming is thought of differently in JS vs C#. In C# you could have a method that takes in 2 points: Point p1 and Point p2 parameters. Since you can see the Type is Point in the parameters it doesn't matter that you abbreviated it so much. In JS though you don't specify types, so point1 and point2 (or pointA/pointB) might be better, unless of course the function name is so obvious (like getMidpoint) in which case p1/p2 or a/b naming would still be clear.

I actually really like reading/writing code that uses really small variable names but are still very obvious given it's context (usually never acronyms though, I despise those). I'd always rather working with something small like p1 rather than something very descriptive like sceneOffsetPoint1, especially if I can read the code above it that shows it being assigned based from the scene center point: let p1 = scene.center + Point(2,3);

Looking at this month's bounty goal only at $2500, I don't think they are raising enough money to justify closing off a revenue stream. I don't have experience in the OSS space but I've seen similar complaints in app development. People expect a $10 app to be $1 or less but don't realize that the $ being brought in doesn't even break even for development costs.

I think there are definitely developers out there that give little to no respect to systems administrators.

I've seen this ignorance even in college professors. In my first programming class in college I took a CS class that had both CS and IT students in it since it was required for both kinds of students. The (CS) professor kept trying to convince students how much better CS was and gave some good arguments (ie: salary) but the most arrogant thing he said is that IT is a subset of CS and that by doing a CS degree you would understand everything it takes to be in IT. He also mentioned how in IT you would be constantly fixing other people's computer problems but as a software engineer you wouldn't need IT's help since you can fix it yourself. The funny part is part-way through my degree I realized that college didn't even offer a real CS degree it was called "CIT with Computer Science Emphasis" which none of my advisers nor professors mentioned would cause issues getting jobs outside of Utah, the best thing I did was leave that school and finish my CS degree elsewhere which caused me to lose a lot of unnecessary credits and almost felt like I was starting over. I feel like I got scammed but that's beside the point I am yet to work for a company where a software engineer gets to manage his own computer without following IT guidelines like my CS prof had described.

tldr; I'm pessimistic about this

This is a hard problem I think. Sometimes news that is interesting and popular is also controversial or just click-bait BS, so you have an ethical vs. interesting news dichotomy. Day-old-news will probably not be interesting to people who already read and discussed the topic the day before. Also consider that if only a few people are curating it there will be other discrediting flaws that might not be caught until more readers see it.

Also, keep in mind that if users get sick of the same kind of articles being posted (which could likely happen given biases of the curators) instead of blaming the users for upvoting (like on HN) they will blame the service instead and will likely stop using the service altogether.

Edit: I could see this working with a small group of individuals that are like-minded to the biases/opinions of the curators.

I like this idea, I've got a handful of side project ideas that I always go back and forth on having/losing steam on and I end up never finishing them.

I also go back and forth on whether my side project should be open sourced or not. Why did you decide to open source all of your personal projects? What if it became something great that you later find out could be sold for extra income, would you regret open-sourcing?

I agree with the opinion that reading code is not like reading literature but I do find it useful to compare the 2 things. The book "The Psychology of Computer Programming" talks about how most good novelists actually read lots of novels while amateur novelists naively think they have enough inspiration without reading ideas written by others. And the same thing happens with programming, most really good programmers have read a lot of code in addition to writing code. I have found this to be the case for myself, the more code I read the more creative inspiration I have available when writing my own code.

You've made some really good points about reading code in both of your posts. I'm fairly new to it, but I've started a daily habit of reading code everyday and I've realized this is an important skill I've omitted in the past.

Since most of the code I read (C# code) can be ran on my platform, I'll sometimes run into that rare piece of code that I can't believe it does what it says it does, in those cases I'll download the repo and debug it and many times be surprised to find there was a gap in my understanding. Reading code helps me find knowledge gaps I didn't even know were there.

I do something similar when reading terminology used in code but for a different reason. I like to steal the good name ideas and I keep them in a mind map I can later look at for naming inspiration.

I've done this recently for a few of the open-source third-party frameworks we use. I'll print out the source code and relevant unit test code for a particular class I'm interested in learning about (or in the case of js code I'll usually just print the entire file). I'll start by reading the unit tests first and then read the actual source. The real benefit of doing this is that I can easily write hand-written notes alongside code to come back and review later. I've found this way of note-taking to be superior to other note-taking tools that allow notes alongside code (like org-mode).

Why is the second version so much better? To me I think it's just a preference of the person reading the code. That it is true is implied, being explicit that it evaluates to true might be more clear to him when he goes back and reads his code.

I'm not sure about the performance differences, but there was a different reason that kept me away from switching to Unity. I've built a couple games in SpriteKit doing it entirely programmatically in code and realized Unity is not setup to work that way at all. If you have experience using SpriteKit Scene Editor then you might not be bothered by that, but I was. Instead of Unity I'm using MonoGame now since it is meant to build the game using just code and I find it was a lot easier to jump into using my existing knowledge from SpriteKit

Your advice here probably applies more to beginner programmers where the goal is to prevent them from just copying/pasting code and following bad practices. It's a good thing for them to learn to write things from scratch. I've been programming for a while and I've felt for a long time like my skills kind of plateaued. Writing things from scratch and reading a lot about design principles haven't really helped me improve at all. But lately I've started to read code, really read it to understand what it does and this has vastly improved my skills.

> There is a finite amount you can learn by reading other people's code. You might find specific idioms you admire and adopt, but you will not - and probably should not - try to conform to other developers' methods

From my own experience I disagree with this since reading other people's code has helped me improve a lot. I've noticed that I am so much more creative and intuitive about good software design when I go to write code now and I believe it is credit to reading code everyday

This is what I love about HN, occasionally the author of the software being discussed will randomly show up in the comment thread

I took a university course where we built an interpreter for MicroScheme. It was a difficult project but was also really awesome and rewarding. I'd like to go back and do it again without deadlines to really understand it better. I think functional programming languages can be a great choice for implementing an interpreter since metaprogramming is their forte and Racket's match function helped a lot, it's like the most powerful thing I've ever seen[1]

[1] https://docs.racket-lang.org/reference/match.html

Thanks for sharing your experience. My set of problems are different but I noticed my experience has been somewhat similar to yours. I'm working in therapy on acceptance and recognizing the internal shaming that came about because of my upbringing.

The frustrating part is that my relationship with my wife (who suffers from borderline personality disorder) makes it extremely difficult when she is fighting the new me that is emerging. She needs constant reassurance about going better places in the future and doesn't like that I'm starting to be ok with the present. The other day I tried to get something done but couldn't since she needed to talk for 6 hours on her day off work and the talk wasn't going the way she liked so it escalated and she got suicidal. She keeps arguing with me to go to a big tech company and make enough money so she never has to work and can be at home with the kids all the time but she's been a stay at home mom before and it ends up being her sitting at home stewing with anger and neglecting the kids and the house. It's hard to make real progress when it is met with so much resistance by loved ones

I think the Socratic method is a much better teaching device. Dogma is the opposite of teaching you to think for yourself. Dogma says "Follow these principles and you'll write good code, don't question it!". Principles need to be challenged and proof needs to be provided how and in what way they are really "best practices". The black and white thinking of dogma are the very reasons why many religious groups don't progress with the modern world and insist they know better than everyone else without having to explain why. Not trying to diss all religions, but I was raised in a very strict one and group-think and anecdotal evidence is used to justify poor decision making. I'd rather be a critical-thinking programmer than a principle-obeying one.

I do the same thing all the time and I'm trying to break this habit since it might be holding me back. I'm trying to realize that I can learn a lot from someone else's work and by diving in and learning the ins and outs and even reading the library's source code I can learn a lot more than experimenting around trying to produce similar functionality myself. Reading code is far more tedious though than being able to creatively experiment with something. The creative learning is important I'm just trying to use it in other applications than re-inventing a wheel that already works well

> it is easier to 'surgically' modify a single method that does one simple thing, than adjust one tiny piece of a much larger function

I would agree for the most part but modifying one small function might cause unwanted side-effects when that function is reused elsewhere (tooling that reports references can help this). A good descriptive function name could help as well. When a function is not meant to be used in multiple places another option is writing a nested function, there might be arguments against that but that helps keep the number of possible method branchings to a better minimum

I started reading the "Real-World Maintainable Software" book and found questionable advice given in the very first section of the book:

> The first guideline indicates that our methods should be short, usually no more than 15 lines of code

Why would that be a good reason to break apart code into different methods? 15 lines isn't even that big

> We can reduce the number of branching points per unit by moving the validation logic to its own method

Before I follow this advice I'd like to know why branching points per method unit is worse than total number of method branches. This wasn't explained to me and I don't see any reason why it should be a guideline worth following

> locality of reference. You shouldn't have to jump around all over a file (much less through several files) to follow the code that does a single thing

This is something I was learning when I was working in Swift, in a WWDC video they called it local reasoning; being able to reason about the code in one particular function without having to worry about state changes elsewhere. Now working in C# it seems to be a common thing to pass an object by reference to a bunch of different functions to fill in it's values and map properties. If you do too much of that it can become a maintenance and debugging nightmare when a property didn't map up the way you wanted it to.

I also agree with what was said in a different comment about not breaking functions up too much if it's not necessary and that would help eliminate this need to modify state in so many places.

My wife is literally the DSM definition of borderline personality disorder (one of the cluster b personality types) and she does have empathy, a lot of it actually. I'm not sure about the other cluster-B types though. Everything is about feelings for her, because her emotions are extreme and hard to regulate. She's the friend that gets called when their life is falling apart because she knows what that feels like almost 100% of the time. Her decisions are always based on emotions. Naturally, because of her lack of emotional health she has unrealistic expectations of me but it's not because she can't empathize with me, it's because she has the emotional health of a child and is afraid of abandonment.