(Part 2) Best products from r/ProgrammerHumor

Depends what you want to learn. Some of my favorites are

• Code by Charles Petzold if you want to know how your computer works under the hood.
  
  
• Peopleware if you want to learn how to manage knowledge workers.
  
  
• Clean Code by Uncle Bob if you want to learn about good practices and program structure. Impressive content, covers much more than I expected.
  
  
• Don't Make Me Think if you want to learn about usability.
  
  
• Algorithms by Robert Sedgewick if you want to learn about DS & algorithms.
  
  
• The Art of UNIX Programming by Eric S. Raymond if you want to learn about the unix philosophy. Lots of hidden gems in there. Have you ever heard: write programs that do one thing and do it well; don't tune for speed until you've measured; imagine all this knowledge distilled to you in one book.
  
  This a good list to get you started :) most of my favorite books are not language specific.

Heh, when I was about nine or ten (late 90's) I would check this book out from my library, keep it for as many renewals as I was allowed, turn it in, wait a day, and check it out again. It was kinda frustrating because the code in the back was for Turbo BASIC (I think?) but I had GWBasic and didn't quite understand how to translate the lines that didn't work.

Finally bought it a couple years ago for nostalgia, since the library no longer had a copy. There were a few others as well, but I can no longer remember the titles. Lots of simple games from a single page of code, I loved it.

I remember my proudest achievement from this era was a flappy-bird style game where you'd fly a spaceship through a randomly-generated cave. It even had a throttle, hull integrity, and particle physics when your ship exploded. I still have the executable, though the original code has long been lost.

**

EDIT: Found some of those old books! Down at the bottom in the 80's section, looks like the publisher released the PDFs for free. My favorite was the [Spacegames*](https://drive.google.com/a/semantic.co.uk/file/d/0Bxv0SsvibDMTNlMwTi1PTlVxc2M/view) book; the "Death Valley" program on pg23 inspired my cave-flyer game. Time to pull out QB64 and get to re-writing some of these!

A good metric is by how expensive the object you're passing around is to make a copy of. In the case where you're passing by value, you're probably returning by value as well so two deep copies there. An alternative is references which are syntactically similar to pass by value but retain the memory niceties of pointers which don't require a full copy but rather just the passing of a memory address.

Typically my rule of thumb is bigger than a pointer use a const reference unless I need a fiddle with the bits in the object I'm passing then I'll go with a pointer. Given enough practice and seeing enough code you sort of get a feel for when it's best to use what, but you kind of need to understand the tradeoffs between how you throw around data.

Passing references everywhere is bad though because it makes it less obvious to person reading/using your code that the object you're passing in could potentially be different object than the one you passed in. If your function takes a pointer it tells the reader that you probably intend to do something with the object's data in the function to change it. Which comes to the second point of using 'const' everywhere which not only informs the reader that the object will not be changed but also binds your function to a contract to not be able to change the value.

For more stuff like this I highly recommend Effective C++ and More Effective C++

ok, here is what you can and maybe should do:

there are glasses for looking longer times at monitors, like these here. they reduce the blue light -> less eye strain and easier to sleep.

try to get off sugar step by step (year by year), not all at once:

• go from sugar rich drinks to mainly water
  
• reduce sugar intake through food (fat is super OK though)
  
• avoid also sugar replacements
  
  do some sports, especially good would be fighting sports, karate, judo, hema, etc. and swimming (especially endurance swimming). or anything else with meditation character.
  
  have a regular sleep cycle.
  
  for school you could attach some weights, those stimulate and reduce the urge for movement. like this and/or this

Things like list comprehensions are really cool. If you run through all of Learn You a Haskell you'll know more about Haskell than me tbh:

http://learnyouahaskell.com/chapters

There's also my dissertation supervisor's book which is really good for grasping the basics:

http://www.amazon.co.uk/Programming-Haskell-Professor-Graham-Hutton/dp/0521692695/ref=la_B001H6QSUC_1_1?s=books&ie=UTF8&qid=1412108611&sr=1-1

Haskell is so powerful when you utilise it to its full potential, but I never really get the chance to play with it any more. Even so, some of the tricks I learnt from Haskell help me in a lot of the python programming I do.

There's also the fact that Haskell really gets you used to a functional style that can actually make javascript quite nice to work with.

https://www.amazon.com/dp/0201633612/?tag=stackoverflow17-20

https://www.amazon.com/Head-First-Design-Patterns-Brain-Friendly/dp/0596007124

https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670

And you could check stack overflow for question on general programming books. I would always go for a general concept functional programming over how to functional programming in haskell.

But I'll be perfectly honest, I'm a victim of the curse of knowledge so I honestly don't know how one should start. What I do remember is that I had huge problems with syntax (how do I tell language X to do a for (Employee e in employeeList), how do you write a switch and stuff, why would I ever need a ternary operator, and like that.

But once you master the basics of how to write x, y and z in your preferred language, you absolutely need to understand design patterns, you absolutely need to understand how code is supposed to be written, you absolutely need to understand data structures, you absolutely need to understand inheritance and polymorphism, you absolutely need to understand lambdas and functional programming.

Then you can get to the more "neat" stuff like the benefits of having immutables, and "job specific stuff" like how to solve race conditions in threading; sockets and web communication, etc.

The hardware limitations are difficult, but I'm really enjoying the challenge. I've been running mongoose-os on an esp8266 which is great for programming in c or c++. You could pick up a node mcu which is a fantastic low cost development board for the esp8266 and be building your own firmware within a couple days.

Hey, no problem man. The source for this particular script is kind of mediocre, but it is here. Note that I included a file called "wow," to get the shell to respond when I typed "wow, real mature, shell".

I want to also mention that when I was learning shell scripting, I made a shell script with a ton of comments to help me understand stuff better. That is located here. And also, for fun, here is a shell script I wrote to make the mouse pointer touch every pixel on your screen. For further learning, I really can't reccommend Mark Sobell's "A Practical Guide to Linux Commands, Editors, and Shell Programming (3rd Edition)" highly enough. It really brought my practical Linux knowledge to a much higher level. I think you can Google that book and get the 2nd edition in pdf form somewhere.

The idea of QA as a non-engineering discipline is pretty old school, and comes from the days when almost all testing was black-box manual testing.

Other than some specific industries, QA is full of engineers.

Look at SDETs, SETs, QEs, SQEs, TEs, and SEQs. You should check out Google, Microsoft or really any of the major tier one software companies. Even many games companies are coming around to the benefits of SEs in QA.

In most places I have worked QA isn’t a separate org anymore, and instead is part of dev (or general software engineering org at least). Though there are often still QA Managers and leads around to help design and implement STLC, and to direct technical efforts related to internal quality focused software development.

For many SEs, the QA track has become equivalent and reasonably attractive over the years.

You can think of it like this. You have Software Engineers, and they have different specializations. Software Engineer, Quality is just a specialization, but no less an SE.

I understand if that isn’t the way things work where you work, but technical expectations have really shifted for QA in most industries.

Edit: People should check out How Google Tests Software - https://www.amazon.com/dp/0321803027/ref=cm_sw_r_cp_api_i_QB4LDbA6GGRWZ

Edit2: One issue currently is that because so many companies have come around to the idea of QA focused SEs, and there has traditionally been prejudice against the concept of QA Engineering in some industries, the market for SDETs is tight as a drum.
In fact, it can be a great track for SEs that think they would enjoy focusing on quality, tools, and automation as disciplines. It isn’t all that unusual to make more money, and have more bargaining power, than a feature dev of similar skill.

I mean, C is for the most part, the foundation on which everything else is built, I know there are some languages not built on it, but most are. C++ is the closest in implementation and syntax, because if I'm not mistaken, Strousop's goal was mainly to extend C and add some more control on the programmer's end.

I started with C++ over Java or C#, because the C++ books at the Half Price Books near me were more interesting and eye catching. My first book was Beginning C++ through Game Programming. It was easy to read, has code that teaches good habits in both readability and commenting, and is engaging. I heartily recommend it for those who are learning C++ and struggling. Game Programming gives you a different perspective on how C++ works under the hood.

I go back to school after having a music degree that I work a job unrelated for years, and they start with Python and Java. All my classmates think I'm crazy for starting on C++.

It's really what works for you, this is the fundamental point of Agile which often gets lost, so if it's working for you that's perfect.

For our teams LEAN makes far more sense. As an example, Kanban replaces velocity with constraints. It makes it immediately obvious which parts of the process are bottlenecks.

Our priorities are set by the business on an available slot basis. We might be able to simultaneously work on three features. If three features are in flight there's zero capacity. The business can pause or abandon a feature, but they have to agree this by quorum (or dictatorially, hierarchy still exists :) ). Once a feature is complete a slot is available and the business can vote on what feature they want next.

So a feature takes as long as a feature takes. We still estimate, but there's no arbitrary sprint boundary to estimate around. We still subdivide tasks as an aid to estimation but again, not to fit in a sprint boundary.

We do stand ups (standing optional) in the morning, still meet as a team, but there's no need for a retrospective. If we are constrained by unanticipated volumes of support, or the task requires input from the business, the task sits in that column so we can see each day that support needs addressing or that someone needs chasing.

There's no formal backlog, the business set their priorities. This doesn't mean the team lead can't meet with the business, discuss future requirements and liaise with the team for informal estimates, complexities, etc. It sounds kind of chaotic but it works across many teams, although interestingly we still use scrum for the sort of transformational, multiyear multi team coordination.

If you're interested in taking a look at this, even if it's just to compare and contrast, take a look at this book. It covers pretty much all the above and a bunch of dev oppsy stuff in novel form. It's not dumbed down, and it is number 1 in its category.

You should be careful about ragging on JS - while it's sometimes fun, the loudest JS-haters are universally just ignorant or unskilled devs. Which, of course, are very common in webdev...

I'd recommend Crockford's Javascript: The Good Parts if you'd be interested in a more positive perspective.

http://webassembly.org/ HTH, HAND

I can easily imagine a book on this subject called more or less that and targeting a similar audience to the goldfish book.

People laughed at the idea of writing Java bytecode by hand, then Andrew and Paul Gower wrote a 3D renderer exactly this way and laughed back all the way to the bank ;)

So I mostly taught myself programming, but i have an engineering background. For context, im working now as a game developer. What i found most helpful once i became confident with my actual problem solving skills in programming was learning programming patterns.

For me that came in the form of [this book] (https://www.amazon.ca/dp/0990582906/ref=cm_sw_r_cp_apa_fSt.Bb1A7WQ5E), which is really just a rehash of how the design patterns in this book can be applied to game development.

Basically once you're more familiar with design patterns, you'll be able to build more manageable code, and better understand others who are using the same patterns.

https://www.amazon.com/Kinivo-BTC450-Bluetooth-Hands-Free-Input/dp/B009NLTW60/ref=sr_1_7?ie=UTF8&qid=1501183446&sr=8-7&keywords=bluetooth+car

This is the most amazing one I've used. Perfect sound clarity on phone calls as well.

Whether or not they have read Code Complete.

http://www.amazon.com/dp/0735619670/ref=cm_sw_r_tw_awdm_ZlAbvb1GP04MC