Ask HN: What language-agnostic programming books should I read? | Hacker News

Ask HN: What language-agnostic programming books should I read? | Hacker News: " What language-agnostic programming books should I read?"



'via Blog this'

braydie/HowToBeAProgrammer: A guide on how to be a Programmer - originally published by Robert L Read

braydie/HowToBeAProgrammer: A guide on how to be a Programmer - originally published by Robert L Read:



To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible. In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one.


This is very subjective and, therefore, this essay is doomed to be personal and somewhat opinionated. I confine myself to problems that a programmer is very likely to have to face in her work. Many of these problems and their solutions are so general to the human condition that I will probably seem preachy. I hope in spite of this that this essay will be useful.

Good Design: What to look for in a Code Reviews

Trisha Gee: What to look for in a Code Reviews

General Computer Science links

2 + 2 = 5

Interesting attempts to make this work on various popular programming languages.


Not light reading!

How to Design Programs

Structure and Interpretation of Computer Programs

Top 30 computer science and programming blogs http://t.co/RSZ1SaRyBe
— Computer Science (@CompSciFact) January 21, 2015

Demystification of #functionalprogramming (immutable, stateless, ..) - http://t.co/9M4ALIXlkU
— Charles Moulliard (@cmoulliard) October 7, 2014

Maven, Git, Jenkins software build tool links

http://www.slideshare.net/tarkasteve/understanding-git-voxxed-vienna-2016

19 Tips For Everyday Git Use

I’ve been using git full time for the past 4 years, and I wanted to share the most practical tips that I’ve learned along the way. Hopefully, it will be useful to somebody out there.

If you are completely new to git, I suggest reading Git Cheat Sheet first. This article is aimed at somebody who has been using git for three months or more.

Table of Contexts:

1. Parameters for better logging
2. Log actual changes in a file
3. Only Log changes for some specific lines in file
4. Log changes not yet merged to the parent branch
5. Extract a file from another branch
6. Some notes on rebasing
7. Remember the branch structure after a local merge
8. Fix your previous commit, instead of making a new commit
9. Three stages in git, and how to move between them
10. Revert a commit, softly
11. See diff-erence for the entire project (not just one file at a time) in a 3rd party diff tool
12. Ignore the white space
13. Only “add” some changes from a file
14. Discover and zap those old branches
15. Stash only some files
16. Good commit messages
17. Git Auto-completion
18. Create aliases for your most frequently used commands
19. Quickly find a commit that broke your feature (EXTRA AWESOME)

GitHub Pull Requests

GitHub’s mission is to make it easier to work together than alone. Throughout the company’s history, they have worked toward this goal by providing an easy way to host Git repositories online and surrounding those repositories with a growing set of collaborative mechanisms that work in the browser and through Git itself.

Pull Requests may be the most important of these innovations. They have enabled increased open-source contributions, provided new ways for enterprise teams to work together, and offered a full-featured code review mechanism—all at the cost of a few Git commands and a simple web user interface. Let’s take a look at how pull requests work and how to use them in open-source and enterprise environments.

Neal Ford: Why Everyone (Eventually) Hates (or Leaves) Maven

Which is why every project eventually hates Maven. Maven is a classic contextual tool: it is opinionated, rigid, generic, and dogmatic, which is exactly what is needed at the beginning of a project. Before anything exists, it’s nice for something to impose a structure, and to make it trivial to add behavior via plug-ins and other pre-built niceties. But over time, the project becomes less generic and more like a real, messy project. Early on, when no one knows enough to have opinions about things like lifecycle, a rigid system is good. Over time, though, project complexity requires developers to spawn opinions, and tools like Maven don’t care.

General Software Development process links

Microsoft Research: Exploding Software-Engineering Myths

The logical assumption would be that more code coverage results in higher-quality code. But what Nagappan and his colleagues saw was that, contrary to what is taught in academia, higher code coverage was not the best measure of post-release failures in the field. Code coverage is not indicative of usage.

What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.

The team observed a definite negative correlation: more assertions and code verifications means fewer bugs. Looking behind the straight statistical evidence, they also found a contextual variable: experience. Software engineers who were able to make productive use of assertions in their code base tended to be well-trained and experienced, a factor that contributed to the end results. These factors built an empirical body of knowledge that proved the utility of assertions.

underscore.io: Creative Scala: A New Introduction to Scala

Creative Scala: A New Introduction to Scala

As we’ve taught more training courses, both free and paid, we’ve seen the need for material that is more basic than Essential Scala. In our free courses we often have students with very little programming experience. The programming patterns in Essential Scala are tough going for them, as they don’t have the background to appreciate the problems we’re solving. In our paid courses we find a lot of time is spent on syntax and other Scala basics that take away from more useful material. Creative Scala is designed to appeal to both groups by covering the very basics of functional programming and Scala is a fun way. We assume some familiarity with another programming language but little or no experience with Scala or other functional languages.

Paris Review: http://www.theparisreview.org/blog/2014/09/05/the-beauty-of-code/

theparisreview.org

as software programs grow bigger and more complex, the code they comprise tends to become unreadable and incomprehensible to human beings. Programmers like to point out that if each line of code, or even each logical statement (which may spread to more than one physical line), is understood to be a component, software systems are the most complicated things that humans have ever built: the Lucent 5ESS switch, used in telephone exchanges, derives its functionality from a hundred million lines of code; the 2008 Fedora 9 distribution of Linux comprises over two hundred million lines of code. No temple, no cathedral has ever contained as many moving parts. So if you’ve ever written code, you understand in your bones the truth of Donald Knuth’s assertion, “Software is hard. It’s harder than anything else I’ve ever had to do.” If you’ve ever written code, the fact that so much software works so much of the time can seem profoundly miraculous.

Thoughtworks Technology Radar

Thoughtworks Technology Radar : Languages and Frameworks

They recommend only enabling the "good parts" of Scala with feature flags.

Software API Links

API Cheat Sheets


New Series: API Design Best Practices