Best products from r/ProgrammerHumor

We found 57 comments on r/ProgrammerHumor discussing the most recommended products. We ran sentiment analysis on each of these comments to determine how redditors feel about different products. We found 200 products and ranked them based on the amount of positive reactions they received. Here are the top 20.

Top comments mentioning products on r/ProgrammerHumor:

u/apieceoffruit · 1 pointr/ProgrammerHumor

Oh god where to begin?

***

Well I Like to think there are level of programming understanding that are relatively tiered.

Tier 1 - How to Code

***
This one is tough as there is no real definitive best answer. My personal primer of choice is

  • Sams Learn Java in 24 hours.

    > Fyi - , that is not "in one day" that is , in 24, 1 hour sessions equating to a hypothetical 4 college lectures a week lasting a month and a half of intensive training. A huge amount of homework is required to accompany that primer.

    so now you can write an app, what next? well. to finish the thought:


    Tier 2 - How to Code...

    so other programmers don't want to hit you over the head for each line in your longest function screaming CYCLOMATIC COMPLEXITYYYY

    **

    Here we talk about how to program
    properly* You want to be looking up Uncle Bob . Head over to

  • www.cleancoders.com

    and check out his video form of his famous book:

  • Clean Code....then buy that book.

    Now you should be writing code that doesn't make other programmers eyes bleed.

    Tier 3 - How to Code..To Solve Problems

    ***
    Here we talk about design patterns. Now, you will bump into a lot of debate over their value but...that is stupid. that is like some people saying all carpentry should be done with a saw and another group saying carpenters should never use a saw. Design patterns are names for recognised ways to solve problems you will hit every day in your programming. They may not always work in your case but at worst they will have you thinking around a problem better.

    For a primer, check out:

  • Head First: Design Patterns

    In fact the entire head first series is great, It is like the For dummies series for programming principles. Great for morons like myself.

    With that read, get the real design pattern book:

  • Elements of Reusable...

    Don't expect to actual understand almost any of this. I read that book cover to cover and it didn't actual click for me till it slapped me in the face when i was in the real world developing business tier applications. Although having read it so many times meant I new which pages to flip to when I was ready.

    Tier 4 - How to Code... For Users

    ***

    This is a whole different kettle of fish. Now you may have written the perfect app to do X with only two buttons, you will find quickly that users are adept at licking the buttons in just the correct order to cause your application to explode. You need to program applications so the cast of jersey shore can use it.

    I am a fan of the blog:

  • Joel on Software.

    Joel (Co-founder of Trello) covers a lot regarding front facing applications and UX that is required reading...even if he a bit cavalier on his approach to testing.

    This is the next part. Testing. You are going to want to Learn about Defensive Programming andTesting. There is a wealth of tutorials over on pluralsight for these.

    Tier 5 - When NOT to Code


    **

    This is a hard step to get to. Realising that copy and pasting code is GREAT!..but for the right reasons. Once you jump over the initial Copy+paste = the greatest thing in the world barrier , most developers grow a level of defiance that borders on the absurd. Preferring to rewrite the wheel instead of using ...the wheel. When you can honestly say you
    could* program it from scratch, it is perfectly okay to use libraries and apis.

    This is where I go to:

  • www.codeproject.com

    and hit up Sacha and others. They show you fairly feature complete and interesting implementations of problems, not just the one or two lines you get from Stack Overflow. Granted this is miles more complicated but it shows not only how to do it, but how to do it right and WHY to do it right. and github of course.

    Tier 6 - Learning From Mistakes

    ***

    Now that you have climbed code mountain and are absorbing the combined knowledge of all the internet geniuses, it is time to see where you went wrong.

    Head over to

  • http://codereview.stackexchange.com/

    and post you functional applications. There a number of people will politely tell you not...how but how to do it better, general improvements in design, logic and reusability. take you through the solid principles and much more. Also..say hello to me if you like :P.

    You don't even have to learn exclusively from your own mistakes.

    check out:

  • www.thedailywtf.com

    and cringe at some examples of real software....and if you don't understand why you should be cringing..learn.

    ***

    Tier 7 - How to think like a programmer


    Now things get a little bit meta. The best way to become a great programmer? don't JUST read programming. Read books like:

  • Zen and the Art of Motorcycle Maintenance

  • Don't Make Me Think

    Read anything and everything, exercise your mind. books on architecture, books on carpentry. any kind of design and problem solving with stretch your understanding of how to climb those brick walls you will hit.

    Read some of the more general programming blogs, like:

  • http://blog.codinghorror.com/

    Read anything and everything.

    Final Thoughts

    ***

    Have fun.

    Check out:

  • www.commitstrip.com
  • www.xkcd.com

    and..well..here.

    I would also say as a personal suggestion, although i left it out of the mandatories up above as it is a bit controversial, I suggest going TDD. Test driven development. It is not for everyone, a hard ethos to get into but in the real world, in business applicable coding...a life saver. Uncle bob is the man for that again.

    Finally I am a fan of Rubber Ducking. Great way to work though problems.

    If you want some final reading, I left them out because everyone and their brother has these (and most of the above) in their top 50 programming book lists so it is a mite redundant:

  • Code Complete
  • The Mythical Man Month
  • The Pragmatic Programmer
  • Refactoring: Improving the Design of Existing Code

    ***
    Enjoy.



u/Versaiteis · 7 pointsr/ProgrammerHumor

Along with the advice from /u/perpetualwalnut the book "The C++ Programming Language" by Bjarne Stroustrup (the language creator). It's limited in being C++11 (we've had 14 as a minor update and now we're approaching the major update of 17) but it's a pretty solid reference for a large portion of the language (>1,000 pages). (Edit:)It's not a book that will teach you C++ directly, but it's a good reference and is pretty extensive while providing motivation and examples of the language features.

For free sources I suggest cppreference.com as a great online reference.

For videos this should give you a good idea of some language semantics that you may or may not be aware of (again by Bjarne).

This video by Sean Parent (former senior programmer/architect, I'm not sure which, of Adobe and worked directly on Photoshop) is a neat intro to how neat using STL can be.

And finally it may also be worth checking out r/cpp for C++ related stuff, they post good articles/videos relevant to the language from time to time.

Sorry for the info dump, this is just all stuff I would have loved to have when I started. C++ is a monolithic language, but you can do some pretty neat/fast things with it.

u/coinaday · 2 pointsr/ProgrammerHumor

There does seem to be a pervasive mindset that (a) taking time to plan is useless (at least anything beyond a vague 'yeah, we know what this means; good enough' ; rarely an attempt to really get rigorous specifications), (b) documenting a system is useless (like there will never be new people to the system, or they should just know by the magic of their rockstar power how everything is intended to work), (c) QA is useless (developers should test their own code, so why do we need QA?)

It seems to come from having seen all of these things done badly and so going to the conclusion that therefore they shouldn't be done.

Like, I get that six months of detailed planning before ever trying to build anything is probably not helpful. But I also think it's useful to take time to slowly walk through various edge cases and really try to hammer out the details and then make something concrete to represent the understanding of what should be done before trying to implement.

And documentation can get stale, or can be pointless. So all the more important to make it a continuous priority to keep fresh and review (like, for instance, developers shouldn't need to be locked into a specific area; have them go take a break and review documentation and code in another section; cross-training is great as well as additional eyes!).

QA, to me, is the most important aspect of software. And yet it's treated like the most unimportant and unnecessary.

To some extent, these things are semantic points and just different perspectives on the same things: in a discussion with my second-line supervisor, we agreed on many things but he simply didn't like the terminology of QA nor the idea of an external group dedicated to testing (!).

To me, quality goes beyond any business logic to a fundamental aesthetic preference beyond even engineering and maintenance practicality. But for any business that intends to still be operating two years down the line, the overall SV attitude that "we're changing so fast we won't need to ever maintain any of this code! test your own code; we don't need QA!" is just so immature.

Which is an ironic critique since I'm the prodigal son who wandered away from the industry with little experience and was barely able to get back in, while I'm arguing against people in senior roles in some cases (one that comes to mind is a CTO of one of the many well-known SV start-ups I was interviewing with was totally gung-ho about self-documenting code and utterly dismissive of the need for any documentation; they were clearly as unimpressed by me as I was by them given the lack of offer).

But I really feel like it would be far more enjoyable (at least to my taste) as well as far more effective to have a strong culture and priority around quality rather than this minimum viable product and ignore the bugs mentality.

I know my critique is somewhat exaggerated and there's a lot of nuance to these things, but this type of thing is exactly why I put so little faith into things like full self-driving being achieved in the near-term. It frankly amazes me that any software works given how it gets built.

There's some garbled saying that comes to mind about if we built bridges the way we build software there'd be a lot more collapses....

Anyhow, I like thinking and talking about this stuff, but I don't expect to ever have the chance to put it into practice. I enjoy my leisure too much to devote decades of my life to someday having the opportunity to prove that "Quality is Free" in software too (that management book from 1980 by a guy working on quality in manufacturing is the most important single thing I would recommend anyone in software to read).

u/Dodobirdlord · 3 pointsr/ProgrammerHumor

There's like a million textbooks and online courses on the subject, and I can't really speak to which ones are good and which ones are not. I've had some success suggesting that people watch this lecture series, but it starts off assuming a fair amount of background. If you're just planning to have some fun noodling around I strongly recommend that you look up a tutorial that suits you on the Keras library for Python, which will let you get started building cat/dog classifiers very easily but which scales up to exploiting the full power of Tensorflow. If you're interested in getting a bit more serious I'd suggest getting comfortable with linear algebra (great book) and making sure you really understand backpropagation. It might sound elitist, but if you can't derive it from scratch on a whiteboard you don't actually understand it, and it will limit your ability to understand why many other techniques are useful.

From there you should have the grounding to understand basically all of the entry-level stuff in the field, from support vector machines to convolutional neural networks.

u/dhruvrajvanshi · 1 pointr/ProgrammerHumor

tl;dr
Step 1: http://craftinginterpreters.com

Step 2: https://www.amazon.com/Types-Programming-Languages-MIT-Press/dp/0262162091


There are a few good ones that I think are good depending what kind of language you're trying to build.

There's a series of blog posts called "Crafting interpreters"

http://craftinginterpreters.com

It's focused on dynamically typed scripting languages like Python and JavaScript but it covers some the basic stuff that you need in all compilers and then some. It's pretty beginner friendly.

On the other end of the spectrum, if you want to learn about implementing statically typed languages, then it's kind of harder to find resources that are not intimidating at first sight (they involve Greek letters and such :/). It's a deep rabbit hole of information and once you start digging, you'll be able to navigate it better. It's not actually that hard if you get used to the basic notation.

I would start by first learning languages with interesting type systems. Haskell is a good one and learn you a Haskell series of blog posts is a good starting point. The point of this exercise is to get familiar with a decent type system. You can't learn how to implement it if you don't know what to implement. Next, there's a good book for learning about type theory called "Types and programming languages" by Benjamin Peirce. If you want something less theoretical, there's also a paper called "Typing Haskell in Haskell" which is a tutorial-ish implementation of Haskell type system. It's what helped me the most in making things click because it showed a concrete implementation.


Also, shameless self plug, I wrote 2 blog posts about implementing basic type inference/checking which is more focused on the code rather than the theory. It's not expertly written but I tried to assume 0 knowledge about type systems. Also, it's written in typescript so it might be less alien than most type system related stuff that tends to be in Haskell.

https://medium.com/@dhruvrajvanshi/type-inference-for-beginners-part-1-3e0a5be98a4b

https://medium.com/@dhruvrajvanshi/type-inference-for-beginners-part-2-f39c33ca9513

Bear in mind that it's not the most clearly written tutorials out there and there are some mistakes which were corrected in edits but it should give you a basic idea.

u/best_of_badgers · 22 pointsr/ProgrammerHumor

Kinda. Giant history lesson follows.

YEC as in "philosophical speculation about the age of the earth" is indeed from the Middle Ages. The Venerable Bede and other writers did do a lot of writing about time and calendars, where they attempted to speculate about the age of the Earth. However, their primary motivations were finding a universal way to calculate the date of Easter without using the Jewish version, which was a point of contention between the Roman and Celtic branches of the Church.

Geology (not biology) provided evidence in the 18th (not 19th) century that the Earth was far older than people had previously assumed. Nobody really knew how old, but it was pretty obvious by the time we started digging canals that there had been a succession of creatures and that these couldn't be explained by a Great Flood. Estimates in the 19th century ranged from a few million years to a few billion years to eternally old. Kelvin did the most thorough calculations based on the temperature of the Earth, but didn't know about radioactivity so dramatically underestimated.

By the start of the 20th century, this was more or less uncontroversial among most Christians, apart from those in some areas of the United States. The problem for them is that they viewed evolution as part of a societal attack on Christianity, which also included historical-critical interpretation of the Biblical texts by university seminarians.

The situation was that in the past 150 years, particularly out on the American frontiers where education was hard to come by, a new doctrine had developed called perspicuity. This doctrine asserted that any literate believer could read the Scriptures and come away with correct Christian doctrine. This doctrine is not a historical Christian doctrine and both the Catholics and the Reformers would have found the idea silly. "Of course we need trained, educated preachers," they'd have said. That's what the Church had always taught.

The American civil war threw this doctrine into crisis, because literate, honest readers of the text came away with nation-dividing views on slavery. So suddenly in the late 19th century, educated people were once again asserted that of course you need to be educated to properly interpret the Bible. It didn't help that many of those people were preaching against traditional interpretations of Christianity, including minimizing the role of miracles in the faith, etc. This offended a lot of evangelicals who still held onto ideas about perspicuity. The reaction to all of that was fundamentalism, which included the idea that the Scriptures are "inerrant".

And that led to what we call "scientific creationism", which is the idea that you should be able to read the Scriptures and, separately, "read" the world, and come up with the same set of truths. This was originally a weird Seventh-Day Adventist thing, promoted by an amateur geologist named George McCready Price. SDA is where the idea of "flood geology" originates, the idea that one can explain the observations of modern geologists using a worldwide flood.

Until the modern synthesis in the 1930s, there was controversy among biologists about whether Darwinian evolution was tenable. (Note: Evolution itself was not controversial, just evolution by natural selection.) Adventist writers were able to seize on this actual uncertainty to promote their ideas, but it wasn't particularly widespread. Adventists have always been a fringe group within Christianity, with some not even accepting them as Christian at all.

American schools mostly avoided controversy by not teaching evolution at all. Stuff like the Scopes Trial did happen and got a lot of publicity, but people need to realize that these got publicity because 1) most people, even most Christians, outside of the frontier thought the situation was stupid and 2) politicians like Bryan could use the publicity as a campaign tool.

Then something happened that led to a massive federal push for updating American schools' science curriculums. The response to this - in 1961 - was The Genesis Flood, a book by engineer Henry Morris which made those weird Seventh-Day Adventist views palatable for evangelicals, who then in the 70s and 80s were turned into a unified political force (for a variety of reasons). And again, the idea was that we should use the Scriptures to interpret scientific findings and vice versa, with the goal of coming up with a unified view of reality. After all, God's truth should be equally apparent in both places.

By the end of the 1970s, young-earth "scientific" creationism in the Price/Morris form was an article of faith for evangelicals. The same is true of the apocalyptic "End Times" stuff, which took an equally circuitous route (involving hippies) to the mainstream. By the time those of us who grew up evangelical in the 90s were born, it was a given.

So yes, when people talk about young-earth creationism, they really are talking about a weird, modern American thing. The version of YEC that was accepted by people like Bede has almost nothing in common with the modern "scientific" version. Your grandparents were probably born before the modern version became prominent.

(Edit: various)

u/threedaysmore · 2 pointsr/ProgrammerHumor

I'll start by saying if you haven't read Clean Code, then it's a great place to see questions like your answered with examples. It gets a little too in the weeds for some people at the end, but the first several chapters are great for explaining how, why, and when to break things up.

What a lot of it comes down to for me (and there are different opinions on what "clean" code looks like or should look like, it's somewhat stylistic) is readability.

No matter what app you're writing, with a little bit of business/domain knowledge I should be able to look at your code without having seen it before and be able to understand what parts of the code are responsible for what logical operations so that if the requirements have changed or a bug was found I should know right where to go.

I made a small example while nomming some lunch (forgive me for typos or obvious errors lol). The example is a Cash Register app that is responsible for totaling the sale amount given a list of items.

___

Here is the orignal code | Here's the refactored Specifically looking at the CalculateTotalSale methods....

So in a small trivial program it's not as easy to see the benefits, but in the refactored version the total sale logic has been broken up into methods. This way, lets say there's a bug in how we're calculating taxes (in a small app like this they're probably wouldn't be, but in an enterprise POS app that's in an international market tax calculation can be a pain) we've made several ways to track down where taxes are being done. We can look at the usages of _taxes to see where it's being modified, and we can look at CalculateTaxes() method since that's where all the tax logic should be. If we find that tax logic is not there, we should either move there, or consider a small change in design to make it flow easier.

Also we've left the CalculateTotalSale method open for extension as well. Noted by the comments, if the business wanted us to write coupon logic we could put it in it's own method and go from there. We've left a pattern for the next person to follow, they'd be able to get into this code and get to work pretty quickly. Patterns do change though, but since we've followed some fairly fundamental designs of class structure it'd be easy for someone to change the pattern if they needed to. They won't have to look all over the code for pieces of logic if we've grouped it well.

All that being said, the first example still works fine and gets the job done, the discussion above is more of engineering vs programming. Just my two cents though! Sorry if I've made any obvious errors or didn't explain this well!

u/ABC_AlwaysBeCoding · 1 pointr/ProgrammerHumor

If I could make a recommendation based on time-tested experience, I'd recommend following the advice of 2 books, Refactoring: Improving The Design Of Existing Code and Growing Object-Oriented Software, Guided By Tests.

Basically, if you are committed to this codebase, you can rewrite bits and pieces of it (while covering them with tests to make sure you didn't break any functionality) and slowly migrate/transform the code to a point where it's more maintainable.

Of course, if you have a manager who you can't convince this is worth spending time on, you might point them to a resource like this about technical debt or perhaps this one to bring it down to dollars and cents (which every manager understands).

I'd also recommend reading this great piece by John Carmack (of id's DOOM fame, and now VR... He's a highly respected OO C programmer, I'm sure you've probably heard of him) about his excursion into 1 month of programming using a "functional style" (it's applicable to any language, actually, including PHP). It has great quotes like this one: "No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."

I promise you that if you can follow some or all of the knowledge I've linked you to, your job will become both less frustrating and more enjoyable (down the line).

u/0XGY · 1 pointr/ProgrammerHumor

I don't think prices for good will change too much. Quantitative Easing added billions of new money into circulation, but the effects on prices was negligible. Yang's plan does not add/print a new money, rather it is just redistributing the money that already exists in the system, so I don't see how prices would change that much.


You are correct that people already on assistance will have a lower net gain, but they will receive other benefits from the dividend:

  • They will save time, money, and hassle around means-testing and re-qualifying for welfare (this is a very real problem addressed thoroughly in this book: https://www.amazon.com/Automating-Inequality-High-Tech-Profile-Police/dp/1250074312).
  • They will also be able to look for employment and other forms of income without fear of loosing out on their benefits.
  • Even a small increase in income is also more impactful when you have lower income.
  • It removes the stigma around "welfare", making it a more stable and less divisive program.
  • Finally, 25% of people living in poverty receive no assistance at all, so for them this is a clear win(https://www.urban.org/research/publication/five-things-you-may-not-know-about-us-social-safety-net).


    The Freedom Dividend is a plan will be a net benefit for 90% of Americans. It doesn't make much sense to demonize it just because a sub-section of Americans will be less benefited by it (when they are still gaining some benefit). For example, would you be against $15 min wage because it doesn't help unemployed people at all? Probably not, because it doesn't make much sense to think about it that way. The fact that it helps mostly everyone, even the middle class, contributes to its unifying nature.


    Finally, I would like to say that the Freedom Dividend is not a perfect solution. Ideally, I believe we would be providing a livable floor, so that no one has to live in poverty. But this is just a first step heading in the right direction.


    Also I really didn't wanna get into a political argument here tbh, was just trying to meme 😂


    edit: formatting
u/kylemit · 2 pointsr/ProgrammerHumor

The key distinction to make here is the difference between Learnability VS Usability

From an Excerpt on CodingHorror:

>In Joel Spolsky's excellent User Interface Design for Programmers, he notes the difference between Usability and Learnability

>> It takes several weeks to learn how to drive a car. For the first few hours behind the wheel, the average teenager will swerve around like crazy. They will pitch, weave, lurch, and sway. If the car has a stick shift they will stall the engine in the middle of busy intersections in a truly terrifying fashion.
>If you did a usability test of cars, you would be forced to conclude that they are simply unusable.

>>This is a crucial distinction. When you sit somebody down in a typical usability test, you're really testing how learnable your interface is, not how usable it is. Learnability is important, but it's not everything. Learnable user interfaces may be extremely cumbersome to experienced users. If you make people walk through a fifteen-step wizard to print, people will be pleased the first time, less pleased the second time, and downright ornery by the fifth time they go through your rigamarole.

>>Sometimes all you care about is learnability: for example, if you expect to have only occasional users. An information kiosk at a tourist attraction is a good example; almost everybody who uses your interface will use it exactly once, so learnability is much more important than usability. But if you're creating a word processor for professional writers, well, now usability is more important.

>>And that's why, when you press the brakes on your car, you don't get a little dialog popping up that says "Stop now? (yes/no)."

u/tech-ninja · 6 pointsr/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.
u/SpoliatorX · 2 pointsr/ProgrammerHumor

Don't Make Me Think is a great book on usability, I'd start with that. If you try to make your interface easy to use you'll often end up making it look better. Beyond that my best advice would be analysing things other people have made and trying to work out which techniques you can appropriate for yourself.

Oh, and whitespace is your friend. Give stuff room to breathe, even if it means you end up needing more space.

u/KillerInstinctUltra · 3 pointsr/ProgrammerHumor

So, there are tons of opinions on this.

Mine is that you write what makes the code easiest to reason about, read, extend, test, and maintain.

The "performance gains" you might gain for writing terse and cryptic "one liners" and non descript variable names are not even detectable unless you are talking about 100,000 lines of JavaScript and are negligible even at that scale as you should be minifying your code anyway, which makes your code terse and cryptic automatically, meaning that you should write your code so it can be easily understood rather than obsessing over microseconds of performance gain at the cost of ease of development.

There is a Zen to this, you can write too much so that the point of what you are trying to achieve is just as lost as if you crammed everything into one line.

Basically, ask your self what can I extract, is this code doing too much, can I break it down into single responsibility functions and orchestrate them in a delegator function, do my variable name's make sense, should this be refactored, what is using this code, is is this duplicated elsewhere, does this code belong in this file or in a service/repository/on the class/centralized configuration file/ etc.

Learn how to write clean code and whether other coders like it or not (usually if they don't it's because they are not disciplined and don't want to be bothered learning the proper way of avoiding common pitfalls and mistakes or following best practices in general)

Do this and I believe you will be a welcome member to almost any dev team.

u/ZukoBestGirl · 7 pointsr/ProgrammerHumor

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.

u/Spectavi · 3 pointsr/ProgrammerHumor

Well if you're serious about taking a run at it, here are the resources I've used to teach myself. I'm self-educated, no degree myself and have been working with ML for the last year at one of those large tech companies I listed, so you can definitely do it. Build a small portfolio or contribute to open-source projects and start applying, it's that simple. Best of luck!

Deep Lizard playlists (beginner through reinforcement learning): https://www.youtube.com/channel/UC4UJ26WkceqONNF5S26OiVw/playlists

MIT Artificial Intelligence Podcast: https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4

Don't know Python? Go here (they also have a Python2 class): https://www.codecademy.com/learn/learn-python-3

Deep Learning with Python (written by the guy who wrote the Keras API, which is the main model building API you should learn first, it works on top of tensorflow/theano/etc.): https://www.amazon.com/Deep-Learning-Python-Francois-Chollet/dp/1617294438/ref=sr_1_3?keywords=deep+learning+with+python&qid=1566500320&s=gateway&sr=8-3

Learn to use Google CoLab when possible, it gives you a free K80 GPU and when you exceed the limits of that you can use a local runtime and use your own hardware. This article has excellent tips and tricks for CoLab: https://medium.com/@oribarel/getting-the-most-out-of-your-google-colab-2b0585f82403

The Math: when if/you're wanting to dive into the nitty-gritty math details the "godfather of modern ML" as they say is Geoffrey Hinton who played a huge role in the invention of deep learning and the mathematical trick that makes it work, back-propagation. You'll need to brush up on differential calculus, summation notation and statistics, but this will help you build your own architectures should you want/need to: https://www.youtube.com/playlist?list=PLoRl3Ht4JOcdU872GhiYWf6jwrk_SNhz9

u/CrazedToCraze · 98 pointsr/ProgrammerHumor

+1, don't just circle jerk and pretend you're above learning patterns before you even understand why they exist. They can be abused, but they exist for good reasons.

I strongly recommend going over Head First Design Patterns to anyone interested.

u/Truth_Be_Told · 1 pointr/ProgrammerHumor

Please see my edited post.

You are overthinking it. There is nothing called "modern way of doing C". Unlike a lot of modern languages which have been conflated with their libraries/APIs and which keep on growing, C is a small and minimal language and has not changed much through its revisions. So you will be good whichever book you start from and as you build up knowledge you will figure out the nuances and internalize "best practices". It really is that simple.

Here are some books to get you started;

u/Toe-Bee · 0 pointsr/ProgrammerHumor

Ok, I was just giving my opinion. If you want to be a better developer read about it: https://en.m.wikipedia.org/wiki/Test-driven_development

It’s simply the idea of writing a test for the desired behaviour before writing the code (let the tests ‘drive’ the development).

For reading on how to write clean code: https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 it has a whole chapter on TDD

u/xxxabc123 · 3 pointsr/ProgrammerHumor

I agree with the Amazon review. Unless you need for a class, or learn an advanced topic not available in other places, I wouldn't touch this book ever. There are much easier algorithms books to read such as https://www.amazon.com/gp/product/032157351X/ This book isn't introductory at all as mentioned on Quora by multiple people https://www.quora.com/What-are-the-best-books-on-algorithms-and-data-structures

And if you've bought this for algorithms interviews preparation, it's better to buy cracking the code interview or similar which has explicit instructions for interview questions.

One more thing to add to the review was the algorithms are written in pseudocode, array indices start with 1 instead of 0, some lines refer to other pages in the book so you can never read a code inside this book sanely.

u/jharger · 1 pointr/ProgrammerHumor

The ones I'm thinking about are tiny bits of plastic with slide-over windows. Pretty cheap and flimsy, but for some reason I like them better than stickers. Basically one of these:

​

https://www.amazon.com/Macboook-Computer-Smartphone-Securtiy-Adhesive/dp/B07FJLFVK3

u/MoonShadeOsu · 8 pointsr/ProgrammerHumor

Sounds like you need this.

Good luck!

u/simonced · 1 pointr/ProgrammerHumor

I know right?! I was like that as well, until I had been enlightened.

Here is my new bible: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

u/Nalha_Saldana · -13 pointsr/ProgrammerHumor

If you have more than two levels of indentation you should break it into multiple methods. If you want to know more I would recommend reading clean code.

Edit: Before you downvote you should know that this isnt my idea, the Clean Code book is even more restrictive and is one of the most recommended books among programmers and companies out there.

u/iheartthejvm · 2 pointsr/ProgrammerHumor

This book changed the way I did things massively and may help you:

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) https://www.amazon.co.uk/dp/0132350882/ref=cm_sw_r_cp_apa_i_lxCwCb8S1W5DZ

u/hubilation · 6 pointsr/ProgrammerHumor

That's exactly how you should code. Uncle Bob taught us that.

Uncle Bob is love, Uncle Bob is life.

Read his book

u/wipqozn · 2 pointsr/ProgrammerHumor

I think I have the same headphones, which means it's these ones: https://www.amazon.ca/Mpow-Bluetooth-headphones-Wireless-Earbuds/dp/B00W4YU578

I love them. I use them when I go to the gym or I'm cleaning around the house.

u/jschelling · 2 pointsr/ProgrammerHumor

Read The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie front to back. It was published in 1988 and is still phenomenal at teaching the fundamentals of CS: primitives, branching, structures, etc. C programming is daunting at first, but future you will appreciate learning CS from its basics as C is about as barebones as you'll want to get. After finishing it you'll learn the majority of what you need to know to begin learning other languages quickly. Run every example in an environment of your choice to see for yourself whats going on in them. I recommend using this online compiler to run the examples as figuring out what programs to use to actually run the code is difficult for a beginner.

u/yoho139 · 7 pointsr/ProgrammerHumor

From wikipedia, and I highly recommend this book as reference material.

u/SolenoidSoldier · 8 pointsr/ProgrammerHumor

If you're interested, check out Clean Code. There is a chapter on just this. Put simply, you shouldn't be afraid to add length to your variable names, so long as they can concisely describe their function. I know, easier said than done, but it's helped steer me away from using acronym and single-letter variable names.

u/TheCluelessDeveloper · 1 pointr/ProgrammerHumor

Eh... documentation should be an overview of the process. Specifics need to be within the code itself. Self-commenting code + coding standards is a real thing.

I would recommend any developer to pick up Clean Code and learn some of the basics on self-commenting code and how to write easy-to-read code.

u/Headpuncher · 1 pointr/ProgrammerHumor

I had PTSD from your class and I wasn't even in attendance.

Obligatory mention of Code book that explains logic gates and some other stuff.

u/jonsaj · 4 pointsr/ProgrammerHumor

I'd recognize that simuduck reference anywhere. it's Head First Design Patterns. We used this book in a class.

u/EibeMandel · 1 pointr/ProgrammerHumor

I can highly recommend the book Code: The Hidden Language of Computer Hardware and Software, it helped me overcome my fear of hardware.

u/bluefisch200 · 2 pointsr/ProgrammerHumor

Please consider reading this 😉

I know you are the sole developer but still...that is just confusing.

u/tanenbaum · 1 pointr/ProgrammerHumor

If the concept of magic numbers is foreign to you, then you should probably read this. Magic numbers are just the tip of the iceberg of bad practices...

u/KieranDevvs · 1 pointr/ProgrammerHumor

No one would ever do that though...

Have you not read Clean code?
https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

A function that needs two lines to declare it is a bad function.
Encapsulate and follow single responsibility.

Any other examples where you need to mix them? Lets not waste time of you posting one example then I show you why its incorrect. Just list me all the instances you believe that you cant use tabs, and ill just correct them all in one post.