50 ms·

How I became a better programmer (2017)

430 points by _ttg 7y ago

dang 7y ago
Discussed at the time: https://news.ycombinator.com/item?id=13918888 https://news.ycombinator.com/item?id=13918888
kqr 7y ago
The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only at increasing levels of abstraction: at first, everything is foreign, then syntax becomes fluff, then APIs become fluff, then patterns, then languages, then compilers, then ... I look forward to learning what the next level of fluff will be. > The majority of the stuff being released every day is just a rehash of the same ideas. Truly revolutionary stuff only happens every few years. Maybe not even that often. I can recommend Old Is the New New by Kevlin Henney for a good, historical perspective on how little actually changes sometimes: https://youtube.com/watch?v=AbgsfeGvg3E https://youtube.com/watch?v=AbgsfeGvg3E Edit: now this was more interesting than I anticipated. What is the next level of fluff? Concurrency? Advanced data structures? Phrasing problems for SMT solvers? Probabilistic modeling? Or are the things I picture as fluff just specific techniques, because the next level of fluff is so meta I wouldn't even recognise it now?
- MaxBarraclough 7y ago
  > then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming.
  - bonoboTP 7y ago
    Or they program different things than you do. In data science for example it's not a big deal to jump across Matlab, Python, Julia, Lua etc. If you know Java, you'll not take very long to be productive in another JVM language or in C#. Yes, deep specialized expertise will take time. Also, switching across paradigms or levels (C -> Prolog or Python -> assembly) will take much longer. But that's not what people usually have in mind when they say switching languages is easy. It's usually the domain that takes longer to learn.
  - battery_cowboy 7y ago
    I'm one of those people, but there's more nuance than that to it. I've learned about 20 different languages to some degree, from Python to brainfuck to Elixir currently. When I learn a new language, I go to the source material, so for elixir I used the tutorials at the elixir home page and their API documentation. I read the tutorials, writing each line of code into my editor, running each, modifying it to see how it works, etc. Then, everytime the tutorial links to or mentions an API, I'll go read that documentation page in full and experimenting. Then I'll make some projects with that language, look at how the more experienced Elixir (or whatever) developers code by exploring their repos, etc. After doing that 10+ times, it becomes easier to see the patterns in languages, and easier to understand how their underlying structure will affect how you have to code. There's only so many ways to write a compiler or interpreter, and if you know how they work and you know that your language is, for example, optimized for tail recursion, then you get your experience from other similar languages as a bonus. I see your point if you're saying, on a surface level, that, "you know one, you know them all," is wrong, but if you dig deeper I think you'll see that, for the experienced (as in: someone who's been around a while) developer, you kinda can say that, with some reservations. I think anyone can do the same thing, it just takes a decade or more to get there. I'm kinda dumb, too, so if I can do it, anyone can.
    - lioeters 7y ago
      I'm with you on this - I don't know so many languages but have studied a wide range, and am fluent in several programming and human languages. What I've found that is that once you learn more than one language with different paradigms, it becomes easier to learn another one with a similar or another different paradigm. As you pointed out, there are only so many ways a language can be designed/structured, and becoming multilingual means getting familiar with the shared (and implicit) models and operations underlying all languages.
- net4all 7y ago
  Not sure how to write this. I am hoping the next level of fluff to be removed will be implementing concrete algorithms in procedural or functional style in day to day coding. Instead we should be leveraging other programs (such as SMT solvers, but not limited to those) to produce a suitable implementations of solutions. That is, we should try to focus more on specifications, in one form or another. So much of the software I work with could plausibly have been written by a machine instead.
- sanderjd 7y ago
  I've been having this experience recently. I used to be a voracious reader of programming books. But for a long time starting, gosh, maybe over 5 years ago, I just couldn't get excited to read them anymore. Just recently I thoroughly enjoyed reading Designing Data Intensive Applications, and I have just started Streaming Systems, which I'm also enjoying a lot. I think this idea of fluff at different levels of abstraction explains it: I used to enjoy reading books about programming languages and frameworks, but at some point it just felt like fluff and I could no longer get through it. But there are books about techniques for solving particular classes of problem (in the case of my recent reading: data processing) which don't feel like fluff to me. But maybe they will eventually, and maybe you're already further on this continuum and would find these books fluffy as well. I'll definitely be thinking about this fluff at different levels of abstraction model and checking my self-education against it as I go now!
yagodragon 7y ago
I've heard so many things about Clojure. I am a CS student with some experience in the most used languages (JS, java, python). Can someone explain in simple cs terms why Clojure is sooo hyped? What can I do with this language that would be harder with other languages? From what I've gathered it's used in data wrangling and manipulation in general but most data-oriented tools are written in Python.
- lymitshn 7y ago
  Maybe more of the hype comes from the fact that its a Lisp. To get a feeling for the "magic" of lisp, I would suggest either watching SICP video lecs[0] or reading the book. I started learning lisp, almost the same time I've started learning programming with Java (college). Honestly I was thinking why they don't just teach us that, instead of Java at that time. Also Clojure is created by a fairly respected dude (afaik) Rich Hickey. His talks and Clojure design decision articles on the site are really insightful. Also this talk[1] also pretty good overview of different paradigms and `Clojure way`, imo. [0]https://youtu.be/-J_xL4IGhJA?list=PLE18841CABEA24090 https://youtu.be/-J_xL4IGhJA?list=PLE18841CABEA24090 [1]https://www.youtube.com/watch?v=vK1DazRK_a0 https://www.youtube.com/watch?v=vK1DazRK_a0
- teataster 7y ago
  I believe it's hyped because is a more practical/modern lisp. I don't think it provides more fundamental benefits than any other lisp than access to a plethora of standard Java libraries. E.g. I cannot Java, but knowing clojure has allowed me to maintain a large inherited Java codebase. Afaik I could not have done that in common lisp (and not only because I don't know cl). I think almost everything is harder when you are not using lisp. Also lisp tends to bring joy to its users for some reason, so there is that. Finally there is a huge difference between Python and clojure data wrangling. Pandas and spark are fundamentally table oriented, but if you are using nested dictionaries (clojure maps) you do not have those tools to help you. No matter what I was doing in clojure, it always involved processing nested maps, it's just the natural approach in the language, kinda like using classes in Java. Hope I managed to clarify something :)
  - 7y ago
jacobush 7y ago
How I became a bitter programmer. (1995-2020)
Twisol 7y ago
> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an understandable foundation. However, I worry that if you focus on the first half of this block, you might think the abstractions aren't important. To a lot of new programmers, abstractions and models are themselves merely "nice" -- if you can get it done without them, clearly they're non-essential, right? I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this.
- Vinnl 7y ago
  ...and also: bad abstractions can be major impediments to it.
  - Twisol 7y ago
    Clarity is primary; good abstractions allow you to achieve it. The fact that bad abstractions harm clarity is something we agree on very strongly.
- ozim 7y ago
  Main point is to be consistent, if it is ugly the same way it is OK. If each time it is ugly different way start thinking about making it consistent. Most value is from consistency, if you make the same mistakes in the same way it is easier to find them. If you make the same mistake in a different way each time, good luck finding it.
- majormajor 7y ago
  > I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this. Bad abstractions and models make it much harder to understand code, though. So for junior devs, yeah, it would often be better to be very, very careful, and think very, very hard about your abstractions before creating them. Everyone wants to turn every problem into some sort of framework loaded with interfaces and different implementations of them vs being ok with "feature X needs to do thing A, B, and D; feature Y needs to do things A, B, C, and E; let's just have them as two separate endpoints with separate biz logical calling those methods sequentially instead of trying to coerce them together."
codr7 7y ago
Once you know a handful of different programming languages, write an interpreted language embedded in your preferred host language. It doesn't have to be fancy, I recommend using Forth or Lisp as a starting point; but write something real, do your thing. I find that most compilers are toys and replicas of existing languages on top of that, which misses the point of designing your own tool. https://github.com/codr7/gfoo https://github.com/codr7/gfoo
movedx 7y ago
Also learn how to run a business. A weird suggestion on the surface but actually very powerful when understood. In short by learning how a business operates, how cash flows and how expensive things are (people, buildings, software, hardware, accountants, lawyers, ...) you'll begin to understand why an MVP is a powerful tool. you'll also appreciate Agile development practices more too. With an MVP you're writing the least amount of code possible, and skipping optimisations, whilst also providing some value to people who can tell you what direction to go in next. That's a business thing - the business needs something in the market ASAP and it needs feedback ASAP. Without this you'd write your stack for three years and then release to a world that moved on two years ago. When you learn how a business is run you begin to understand that getting to market with a less than ideal code base is actually desirable and something to embraced. All of sudden you'll come to understand that money burns quickly so you should learn to develop code to get to market and not to be the fastest code it can be (yet, at least.) I find the best programmers I've worked with are those that can produce something quickly and optimise it later on.
- einpoklum 7y ago
  I've found the ability to produce something quickly is almost orthogonal to being a "good programmer" (unless you define goodness that way.) Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice.
  - ratww 7y ago
    > Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice. Fred Brooks has a chapter in Mythical Man Month where he mentions different programmers having different roles within "Surgical Software Team" but that never took off. I wonder if updating that to 2020 would make more sense to have a group of people shipping features full-steam ahead, another reviewing the code for mistakes, and then having other folks refactoring the mess, behind both of them. I would frankly enjoy being in just one the three positions, any of them, much more than the position I'm currently: having to be all three at the same time.
funylon 7y ago
"I stick things on the global object until I know what I'm doing." Magical sentence that.
jaequery 7y ago
About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye opening experience. Then I wrote an MVC framework from scratch because I thought others were too heavy (ZF, Symfony, etc). It helped me understand an application development at a deeper level, figuring out the best strategy for code modularization, organization, and performance. It helped me to learn creating something that looks so painlessly easy to use is a pretty difficult task (there will always be something ugly sticking out). It took me on a ride of what happens with extreme level of abstractions breaking up code for each roles and a simpler route much like the Sinatra / Express bootstrap approach. I've found a new level of respect for those who develops codes at a macro-level (frameworks / libraries). There are lot of thoughts and love been applied to them. DHL (Rails) is up there, as well as John Resig (jQuery). I'll also give a shout out to Sequel (Jeremy Evans) while at it for creating an ORM that is almost perfect. Vue.js (Evan You) also particularly deserves a lot of credit for what he is doing in the front-end world. I like React too, can be fun, but I did not like the whole Redux experience. I think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple.
- acemarke 7y ago
  > I did not like the whole Redux experience Out of curiosity, anything specific that concerned you? If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns in practices in our Style Guide docs page [2] that should result in simpler and easier to understand code. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks [2] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide
Crazyontap 7y ago
My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a Class would have been better than a function. - I love old boring technologies and believe you can still make amazing websites with just PHP and jQuery. - I don't come up with clever one-liners anymore. I write a 10 line for loop which I could easily replace with a clever one-line code golf. - Instead of writing my own code, I usually search Stackoverflow first to see if I can do some copy-paste it instead.
- scabarott 7y ago
  +1. Add: - Use long expressive variable/function/class names that tell me exactly what this variable/function/class does I have to constantly fight the urge to have code fit in the littlest amount of space possible.
  - chrismcb 7y ago
    Variable names sound be succinct . They don't need to be short, but they also shouldn't be essays. I had one coworker who would essentially write everything the function did. Variable names would be 100+ chars. It was impossible. Variable names should be as long as needed , but no longer.
    - mattchamb 7y ago
      I use variable, function and class names as a rough guide on whether I need to refactor. If I name it accurately and the name gets too long, its probably doing too much.
- quickthrower2 7y ago
  Most of that is good. One factor is if you are writing code for yourself to maintain or a team. If it is for a team, you need to take into account if other people can understand your code. Practices like SOLID and just using the type system well don't make it slower to write code but will help maintenance down the road.
uk_programmer 7y ago
Some of it this was spot on, especially doing research. Very rarely you will be doing something completely novel and it always good to look at how other people have solved a problem. However the old "Learn C" and "Write a compiler" which are within meme territory tbh. It is more important generally to understand what a particular in whatever language you are using to know what the compiler / interpreter / run-time is doing under the hood as most developers will be working with a high level language. I've seen a lot of "how to improve as a programmer" articles and IMO what seems to be left out is learning how to do things as simply as possible. Many of the software systems I've worked on is so over-engineered, many simple websites are huge both client and server side and they usually don't warrant it.
xwdv 7y ago
I became a better programmer once I committed to mastering Vim. Don’t know why, but the whole struggle of using it changed the way I thought about code and I gained the power to code at the speed of thought.
- fossuser 7y ago
  I think I actually became better when I stopped spending time messing around with tools and environments and focused on just the programming part. Sane defaults, know the tool and how to use it, but don’t waste time on configuration. When possible choose the standard tool for the job (IntelliJ for me). It’s still fun to yak shave, mess with things, play with the terminal etc. but at least for me I found that the time spent doing that was the opposite of productive.
  - hombre_fatal 7y ago
    Like playing an instrument or learning a language, learning Vim/Emacs is something you're glad younger-you did because now you certainly couldn't be bothered. Then again, these days I just use whatever vim-mode solution there is in VSCode, IntelliJ, etc. and move on. Kind of like how I prefer a GUI for Git these days. It would blow the mind of my younger self. I just have so many other things going on in my life and on my plate.
sp527 7y ago
Doesn’t expound upon two of the most important things: (1) focus on business value over technical challenge (if anything this preaches the opposite) and (2) learn how to get as close as possible to the global optimum in the 3D space formed by time, cost, and quality, depending on the situation.
- kqr 7y ago
  And (3) read Deming to find out that the 3D space formed by time, cost, and quality does not look like one might think it does – for anything but the quickest of prototypes, increased quality reduces total time and cost!
non-entity 7y ago
> But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely changes how I am going to solve it. Personally this typically ends up in me just dropping the problem altogether
marta_morena_23 7y ago
"Don't spend much time on making your code look nice"... Well, thanks a lot. You just made your code much harder to read, improve, change and check for correctness. This is actually a self-contradiction. If the code changes often, then its even more important to make it "look nice". This is something that beginner programmers don't get on several levels: Nice code * can be reviewed more quickly (broadcasting effect) * can be checked for correctness much more easily * is pleasant to work with * can be changed more easily * can often even compiled into more efficient machine code The reason why beginners (and this is not about time invested! Many programmers still are beginners after 30 years in the field) think code doesn't need to look nice is mostly because 1. They don't consider that most of the cost of code comes from maintenance. Writing it is really A FRACTION of the time people will spend with your code over time. 2. They don't consider that creating bugs is one of the most expensive parts of software development. 3. They don't consider that code is read far more often than it is being written. 4. They are simply not ABLE to produce good code and doing so would take them a lot of time. Now giving the advice to not focus on good/nice code is a recipe for staying a beginner for the rest of your life and making every project your work on a nightmare for everyone else involved.
- jspash 7y ago
  FYI - the author of the blog post created https://prettier.io/ https://prettier.io/ which is a very opinionated (automatic) javascript code formatter. His assertion about "nice code" was that you shouldn't spend effort on making it look nice. Let a tool do that for you. Personally I dislike some the default formats that prettier have chosen but if it prevents a single minute of discussion on my team about how the should be formatted, it pays dividends over time. And eventually we, as humans seem to get used to just about anything.
- wccrawford 7y ago
  While I agree, what they actually said was "if you spend most of your time making your code look pretty", which is obviously too much time, IMO. There needs to be balance.
cryptonector 7y ago
> Understand continuations - Continuations are a low-level control flow mechanism. Excellent advice right there! > Scheme is the only language to implement them, and while you will never use them in production, they will change how you think about control flow. I wrote a blog post trying to explain them. Hmm, well, many languages compile to a continuation passing style (CPS) intermediate. And in many languages it is important to understand continuations to understand how they work. For example, laziness in Haskell is essentially all about continuations and continuation passing style. What is CPS? Anyone who has been in callback hell knows. In CPS a continuation is just the closure you pass to some function that it will call when it's done. In fact, even in C, the act of returning from a function is very much like the act of calling a continuation, except that by unwinding the stack, the magic of Scheme continuations is lost.
- PaulAJ 7y ago
  "... you will never use them in production ..." I'm a Haskell programmer. Continuations are part of my everyday toolbox.
justlexi93 7y ago
I feel like learning is a continuous process, technology changes from time to time so might stay updated with all the latest trend.
MUHAMMADRIZWAN 7y ago
https://thekrjaan.com/how-to-make-your-home-safe/ https://thekrjaan.com/how-to-make-your-home-safe/
mit_cs 7y ago
Your reasoning for learning C is biased (perhaps you don't know it well as you suggested the others to know the basics)! At the end, hardware understands only values. C is a minimal, efficient and readable language which survived for decades although there are hundreds of other programming languages. It remains an active programming language as long as there is a good compiler support.
- tjpnz 7y ago
  Many of the complaints I read about C these days often boil down to a lack of understanding, I think you're right to suggest that the author doesn't know it very well. I also suspect that they haven't taken the time to find and read good C code.
LessDmesg 7y ago
TIL Scheme is the only language that implements continuations.
collyw 7y ago
One thing that helped me a to was to build a system myself and maintain it for a few years. That way you see what areas come back and cause you trouble over and over again. If I didn't understand a bit of code I wrote a few months ago, it was probably too complex and worth refactoring. As it was my own system, I couldn't blame anyone else's poor design decisions. I noticed that keeping the logic as close to the database was generally the way to go. Avoiding changing the database schema and making up for it at the application level was basically adding technical debt.
augustk 7y ago
"The most experienced programmer uses hacks all the time; the important part is that you're getting stuff done." I couldn't disagree more, the grown up programmers use a strategic approach, not a tactical one. As Jonh Ousterhout put it in his book A Philosophy of Software Design "The first step towards becoming a good software designer is to realize that working code isn't enough."
- rooam-dev 7y ago
  100% agree. The "hacks" and "get stuff done" approach gains quick and short benefit, which probably fits a freelancer/contractor role. Maintainable and testable code should be implied. It's not about how fast you get to code to production, it's about how fast code/product can be adapted to new or unexpected requirements.
  - gazelle21 7y ago
    That sounds great but in real life, when your boss wants his crud app fixed yesterday and the previous dev left no documentation for random code, you have to do what you have to do.
- ewidar 7y ago
  Judging by the rest of the article, I don't think the author is advocating pushing hacks to production. But rather to use hacks to move forward, and then improve once you have a working version.
- apotheon 7y ago
  Elsewhere in this discussion, I described my first Flux experience. In that same job, the boss decided (after we switched to a pseudo-Flux, Frankenstein's monster of MVC component libs that slowed development to an excruciating crawl) to bring in a consultant to "help". He was the "crap out apparently-working code quickly" brand of "10x Programmer". Some basic functionality for new features got added in a hurry, over a couple weeks' time. The following couple weeks were dedicated to fixing everything he wrote. Yes, I agree: "grown up" programmers think beyond what seems to work right now. Sure, I use dirty hacks semi-regularly, but only when I'm first feeling out how something works. It doesn't last more than a couple hours, usually far less, because the point isn't to commit that code but to learn how to think about the problem so I can do it right, and a "done right" rewrite takes less time to get working than the initial dirty hack. The "done right" rewrite also doesn't impose tremendous maintenance and continuing development costs over months to come the way the dirty hack would. If the author means real programmers use dirty hacks to figure out what they're doing, then they make it right, that's fine. If not, that's not fine at all.
gchamonlive 7y ago
SICP is really cool! I would follow up with Practical Common Lisp right after, for insight into a more usable Lisp dialect.
brunoamuniz 7y ago
"Get uncomfortable" is one of the best advise in anyones life =P stay out of your comfort zone. Also teaching something is a good way to learn more and more about an specific subject

430 points by _ttg 7y ago

dang 7y ago

Discussed at the time: https://news.ycombinator.com/item?id=13918888 https://news.ycombinator.com/item?id=13918888

kqr 7y ago

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only at increasing levels of abstraction: at first, everything is foreign, then syntax becomes fluff, then APIs become fluff, then patterns, then languages, then compilers, then ... I look forward to learning what the next level of fluff will be. > The majority of the stuff being released every day is just a rehash of the same ideas. Truly revolutionary stuff only happens every few years. Maybe not even that often. I can recommend Old Is the New New by Kevlin Henney for a good, historical perspective on how little actually changes sometimes: https://youtube.com/watch?v=AbgsfeGvg3E https://youtube.com/watch?v=AbgsfeGvg3E Edit: now this was more interesting than I anticipated. What is the next level of fluff? Concurrency? Advanced data structures? Phrasing problems for SMT solvers? Probabilistic modeling? Or are the things I picture as fluff just specific techniques, because the next level of fluff is so meta I wouldn't even recognise it now?

MaxBarraclough 7y ago
> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming.
- bonoboTP 7y ago
  Or they program different things than you do. In data science for example it's not a big deal to jump across Matlab, Python, Julia, Lua etc. If you know Java, you'll not take very long to be productive in another JVM language or in C#. Yes, deep specialized expertise will take time. Also, switching across paradigms or levels (C -> Prolog or Python -> assembly) will take much longer. But that's not what people usually have in mind when they say switching languages is easy. It's usually the domain that takes longer to learn.
- battery_cowboy 7y ago
  I'm one of those people, but there's more nuance than that to it. I've learned about 20 different languages to some degree, from Python to brainfuck to Elixir currently. When I learn a new language, I go to the source material, so for elixir I used the tutorials at the elixir home page and their API documentation. I read the tutorials, writing each line of code into my editor, running each, modifying it to see how it works, etc. Then, everytime the tutorial links to or mentions an API, I'll go read that documentation page in full and experimenting. Then I'll make some projects with that language, look at how the more experienced Elixir (or whatever) developers code by exploring their repos, etc. After doing that 10+ times, it becomes easier to see the patterns in languages, and easier to understand how their underlying structure will affect how you have to code. There's only so many ways to write a compiler or interpreter, and if you know how they work and you know that your language is, for example, optimized for tail recursion, then you get your experience from other similar languages as a bonus. I see your point if you're saying, on a surface level, that, "you know one, you know them all," is wrong, but if you dig deeper I think you'll see that, for the experienced (as in: someone who's been around a while) developer, you kinda can say that, with some reservations. I think anyone can do the same thing, it just takes a decade or more to get there. I'm kinda dumb, too, so if I can do it, anyone can.
  - lioeters 7y ago
    I'm with you on this - I don't know so many languages but have studied a wide range, and am fluent in several programming and human languages. What I've found that is that once you learn more than one language with different paradigms, it becomes easier to learn another one with a similar or another different paradigm. As you pointed out, there are only so many ways a language can be designed/structured, and becoming multilingual means getting familiar with the shared (and implicit) models and operations underlying all languages.
net4all 7y ago
Not sure how to write this. I am hoping the next level of fluff to be removed will be implementing concrete algorithms in procedural or functional style in day to day coding. Instead we should be leveraging other programs (such as SMT solvers, but not limited to those) to produce a suitable implementations of solutions. That is, we should try to focus more on specifications, in one form or another. So much of the software I work with could plausibly have been written by a machine instead.
sanderjd 7y ago
I've been having this experience recently. I used to be a voracious reader of programming books. But for a long time starting, gosh, maybe over 5 years ago, I just couldn't get excited to read them anymore. Just recently I thoroughly enjoyed reading Designing Data Intensive Applications, and I have just started Streaming Systems, which I'm also enjoying a lot. I think this idea of fluff at different levels of abstraction explains it: I used to enjoy reading books about programming languages and frameworks, but at some point it just felt like fluff and I could no longer get through it. But there are books about techniques for solving particular classes of problem (in the case of my recent reading: data processing) which don't feel like fluff to me. But maybe they will eventually, and maybe you're already further on this continuum and would find these books fluffy as well. I'll definitely be thinking about this fluff at different levels of abstraction model and checking my self-education against it as I go now!

yagodragon 7y ago

I've heard so many things about Clojure. I am a CS student with some experience in the most used languages (JS, java, python). Can someone explain in simple cs terms why Clojure is sooo hyped? What can I do with this language that would be harder with other languages? From what I've gathered it's used in data wrangling and manipulation in general but most data-oriented tools are written in Python.

lymitshn 7y ago
Maybe more of the hype comes from the fact that its a Lisp. To get a feeling for the "magic" of lisp, I would suggest either watching SICP video lecs[0] or reading the book. I started learning lisp, almost the same time I've started learning programming with Java (college). Honestly I was thinking why they don't just teach us that, instead of Java at that time. Also Clojure is created by a fairly respected dude (afaik) Rich Hickey. His talks and Clojure design decision articles on the site are really insightful. Also this talk[1] also pretty good overview of different paradigms and `Clojure way`, imo. [0]https://youtu.be/-J_xL4IGhJA?list=PLE18841CABEA24090 https://youtu.be/-J_xL4IGhJA?list=PLE18841CABEA24090 [1]https://www.youtube.com/watch?v=vK1DazRK_a0 https://www.youtube.com/watch?v=vK1DazRK_a0
teataster 7y ago
I believe it's hyped because is a more practical/modern lisp. I don't think it provides more fundamental benefits than any other lisp than access to a plethora of standard Java libraries. E.g. I cannot Java, but knowing clojure has allowed me to maintain a large inherited Java codebase. Afaik I could not have done that in common lisp (and not only because I don't know cl). I think almost everything is harder when you are not using lisp. Also lisp tends to bring joy to its users for some reason, so there is that. Finally there is a huge difference between Python and clojure data wrangling. Pandas and spark are fundamentally table oriented, but if you are using nested dictionaries (clojure maps) you do not have those tools to help you. No matter what I was doing in clojure, it always involved processing nested maps, it's just the natural approach in the language, kinda like using classes in Java. Hope I managed to clarify something :)
- 7y ago

jacobush 7y ago

How I became a bitter programmer. (1995-2020)

Twisol 7y ago

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an understandable foundation. However, I worry that if you focus on the first half of this block, you might think the abstractions aren't important. To a lot of new programmers, abstractions and models are themselves merely "nice" -- if you can get it done without them, clearly they're non-essential, right? I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this.

Vinnl 7y ago
...and also: bad abstractions can be major impediments to it.
- Twisol 7y ago
  Clarity is primary; good abstractions allow you to achieve it. The fact that bad abstractions harm clarity is something we agree on very strongly.
ozim 7y ago
Main point is to be consistent, if it is ugly the same way it is OK. If each time it is ugly different way start thinking about making it consistent. Most value is from consistency, if you make the same mistakes in the same way it is easier to find them. If you make the same mistake in a different way each time, good luck finding it.
majormajor 7y ago
> I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this. Bad abstractions and models make it much harder to understand code, though. So for junior devs, yeah, it would often be better to be very, very careful, and think very, very hard about your abstractions before creating them. Everyone wants to turn every problem into some sort of framework loaded with interfaces and different implementations of them vs being ok with "feature X needs to do thing A, B, and D; feature Y needs to do things A, B, C, and E; let's just have them as two separate endpoints with separate biz logical calling those methods sequentially instead of trying to coerce them together."

codr7 7y ago

Once you know a handful of different programming languages, write an interpreted language embedded in your preferred host language. It doesn't have to be fancy, I recommend using Forth or Lisp as a starting point; but write something real, do your thing. I find that most compilers are toys and replicas of existing languages on top of that, which misses the point of designing your own tool. https://github.com/codr7/gfoo https://github.com/codr7/gfoo

movedx 7y ago

Also learn how to run a business. A weird suggestion on the surface but actually very powerful when understood. In short by learning how a business operates, how cash flows and how expensive things are (people, buildings, software, hardware, accountants, lawyers, ...) you'll begin to understand why an MVP is a powerful tool. you'll also appreciate Agile development practices more too. With an MVP you're writing the least amount of code possible, and skipping optimisations, whilst also providing some value to people who can tell you what direction to go in next. That's a business thing - the business needs something in the market ASAP and it needs feedback ASAP. Without this you'd write your stack for three years and then release to a world that moved on two years ago. When you learn how a business is run you begin to understand that getting to market with a less than ideal code base is actually desirable and something to embraced. All of sudden you'll come to understand that money burns quickly so you should learn to develop code to get to market and not to be the fastest code it can be (yet, at least.) I find the best programmers I've worked with are those that can produce something quickly and optimise it later on.

einpoklum 7y ago
I've found the ability to produce something quickly is almost orthogonal to being a "good programmer" (unless you define goodness that way.) Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice.
- ratww 7y ago
  > Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice. Fred Brooks has a chapter in Mythical Man Month where he mentions different programmers having different roles within "Surgical Software Team" but that never took off. I wonder if updating that to 2020 would make more sense to have a group of people shipping features full-steam ahead, another reviewing the code for mistakes, and then having other folks refactoring the mess, behind both of them. I would frankly enjoy being in just one the three positions, any of them, much more than the position I'm currently: having to be all three at the same time.

funylon 7y ago

"I stick things on the global object until I know what I'm doing." Magical sentence that.

jaequery 7y ago

About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye opening experience. Then I wrote an MVC framework from scratch because I thought others were too heavy (ZF, Symfony, etc). It helped me understand an application development at a deeper level, figuring out the best strategy for code modularization, organization, and performance. It helped me to learn creating something that looks so painlessly easy to use is a pretty difficult task (there will always be something ugly sticking out). It took me on a ride of what happens with extreme level of abstractions breaking up code for each roles and a simpler route much like the Sinatra / Express bootstrap approach. I've found a new level of respect for those who develops codes at a macro-level (frameworks / libraries). There are lot of thoughts and love been applied to them. DHL (Rails) is up there, as well as John Resig (jQuery). I'll also give a shout out to Sequel (Jeremy Evans) while at it for creating an ORM that is almost perfect. Vue.js (Evan You) also particularly deserves a lot of credit for what he is doing in the front-end world. I like React too, can be fun, but I did not like the whole Redux experience. I think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple.

acemarke 7y ago
> I did not like the whole Redux experience Out of curiosity, anything specific that concerned you? If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns in practices in our Style Guide docs page [2] that should result in simpler and easier to understand code. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks [2] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide

Crazyontap 7y ago

My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a Class would have been better than a function. - I love old boring technologies and believe you can still make amazing websites with just PHP and jQuery. - I don't come up with clever one-liners anymore. I write a 10 line for loop which I could easily replace with a clever one-line code golf. - Instead of writing my own code, I usually search Stackoverflow first to see if I can do some copy-paste it instead.

scabarott 7y ago
+1. Add: - Use long expressive variable/function/class names that tell me exactly what this variable/function/class does I have to constantly fight the urge to have code fit in the littlest amount of space possible.
- chrismcb 7y ago
  Variable names sound be succinct . They don't need to be short, but they also shouldn't be essays. I had one coworker who would essentially write everything the function did. Variable names would be 100+ chars. It was impossible. Variable names should be as long as needed , but no longer.
  - mattchamb 7y ago
    I use variable, function and class names as a rough guide on whether I need to refactor. If I name it accurately and the name gets too long, its probably doing too much.
quickthrower2 7y ago
Most of that is good. One factor is if you are writing code for yourself to maintain or a team. If it is for a team, you need to take into account if other people can understand your code. Practices like SOLID and just using the type system well don't make it slower to write code but will help maintenance down the road.

uk_programmer 7y ago

Some of it this was spot on, especially doing research. Very rarely you will be doing something completely novel and it always good to look at how other people have solved a problem. However the old "Learn C" and "Write a compiler" which are within meme territory tbh. It is more important generally to understand what a particular in whatever language you are using to know what the compiler / interpreter / run-time is doing under the hood as most developers will be working with a high level language. I've seen a lot of "how to improve as a programmer" articles and IMO what seems to be left out is learning how to do things as simply as possible. Many of the software systems I've worked on is so over-engineered, many simple websites are huge both client and server side and they usually don't warrant it.

xwdv 7y ago

I became a better programmer once I committed to mastering Vim. Don’t know why, but the whole struggle of using it changed the way I thought about code and I gained the power to code at the speed of thought.

fossuser 7y ago
I think I actually became better when I stopped spending time messing around with tools and environments and focused on just the programming part. Sane defaults, know the tool and how to use it, but don’t waste time on configuration. When possible choose the standard tool for the job (IntelliJ for me). It’s still fun to yak shave, mess with things, play with the terminal etc. but at least for me I found that the time spent doing that was the opposite of productive.
- hombre_fatal 7y ago
  Like playing an instrument or learning a language, learning Vim/Emacs is something you're glad younger-you did because now you certainly couldn't be bothered. Then again, these days I just use whatever vim-mode solution there is in VSCode, IntelliJ, etc. and move on. Kind of like how I prefer a GUI for Git these days. It would blow the mind of my younger self. I just have so many other things going on in my life and on my plate.

sp527 7y ago

Doesn’t expound upon two of the most important things: (1) focus on business value over technical challenge (if anything this preaches the opposite) and (2) learn how to get as close as possible to the global optimum in the 3D space formed by time, cost, and quality, depending on the situation.

kqr 7y ago
And (3) read Deming to find out that the 3D space formed by time, cost, and quality does not look like one might think it does – for anything but the quickest of prototypes, increased quality reduces total time and cost!

non-entity 7y ago

> But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely changes how I am going to solve it. Personally this typically ends up in me just dropping the problem altogether

marta_morena_23 7y ago

"Don't spend much time on making your code look nice"... Well, thanks a lot. You just made your code much harder to read, improve, change and check for correctness. This is actually a self-contradiction. If the code changes often, then its even more important to make it "look nice". This is something that beginner programmers don't get on several levels: Nice code * can be reviewed more quickly (broadcasting effect) * can be checked for correctness much more easily * is pleasant to work with * can be changed more easily * can often even compiled into more efficient machine code The reason why beginners (and this is not about time invested! Many programmers still are beginners after 30 years in the field) think code doesn't need to look nice is mostly because 1. They don't consider that most of the cost of code comes from maintenance. Writing it is really A FRACTION of the time people will spend with your code over time. 2. They don't consider that creating bugs is one of the most expensive parts of software development. 3. They don't consider that code is read far more often than it is being written. 4. They are simply not ABLE to produce good code and doing so would take them a lot of time. Now giving the advice to not focus on good/nice code is a recipe for staying a beginner for the rest of your life and making every project your work on a nightmare for everyone else involved.

jspash 7y ago
FYI - the author of the blog post created https://prettier.io/ https://prettier.io/ which is a very opinionated (automatic) javascript code formatter. His assertion about "nice code" was that you shouldn't spend effort on making it look nice. Let a tool do that for you. Personally I dislike some the default formats that prettier have chosen but if it prevents a single minute of discussion on my team about how the should be formatted, it pays dividends over time. And eventually we, as humans seem to get used to just about anything.
wccrawford 7y ago
While I agree, what they actually said was "if you spend most of your time making your code look pretty", which is obviously too much time, IMO. There needs to be balance.

cryptonector 7y ago

> Understand continuations - Continuations are a low-level control flow mechanism. Excellent advice right there! > Scheme is the only language to implement them, and while you will never use them in production, they will change how you think about control flow. I wrote a blog post trying to explain them. Hmm, well, many languages compile to a continuation passing style (CPS) intermediate. And in many languages it is important to understand continuations to understand how they work. For example, laziness in Haskell is essentially all about continuations and continuation passing style. What is CPS? Anyone who has been in callback hell knows. In CPS a continuation is just the closure you pass to some function that it will call when it's done. In fact, even in C, the act of returning from a function is very much like the act of calling a continuation, except that by unwinding the stack, the magic of Scheme continuations is lost.

PaulAJ 7y ago
"... you will never use them in production ..." I'm a Haskell programmer. Continuations are part of my everyday toolbox.

justlexi93 7y ago

I feel like learning is a continuous process, technology changes from time to time so might stay updated with all the latest trend.

MUHAMMADRIZWAN 7y ago

https://thekrjaan.com/how-to-make-your-home-safe/ https://thekrjaan.com/how-to-make-your-home-safe/

mit_cs 7y ago

Your reasoning for learning C is biased (perhaps you don't know it well as you suggested the others to know the basics)! At the end, hardware understands only values. C is a minimal, efficient and readable language which survived for decades although there are hundreds of other programming languages. It remains an active programming language as long as there is a good compiler support.

tjpnz 7y ago
Many of the complaints I read about C these days often boil down to a lack of understanding, I think you're right to suggest that the author doesn't know it very well. I also suspect that they haven't taken the time to find and read good C code.

LessDmesg 7y ago

TIL Scheme is the only language that implements continuations.

collyw 7y ago

One thing that helped me a to was to build a system myself and maintain it for a few years. That way you see what areas come back and cause you trouble over and over again. If I didn't understand a bit of code I wrote a few months ago, it was probably too complex and worth refactoring. As it was my own system, I couldn't blame anyone else's poor design decisions. I noticed that keeping the logic as close to the database was generally the way to go. Avoiding changing the database schema and making up for it at the application level was basically adding technical debt.

augustk 7y ago

"The most experienced programmer uses hacks all the time; the important part is that you're getting stuff done." I couldn't disagree more, the grown up programmers use a strategic approach, not a tactical one. As Jonh Ousterhout put it in his book A Philosophy of Software Design "The first step towards becoming a good software designer is to realize that working code isn't enough."

rooam-dev 7y ago
100% agree. The "hacks" and "get stuff done" approach gains quick and short benefit, which probably fits a freelancer/contractor role. Maintainable and testable code should be implied. It's not about how fast you get to code to production, it's about how fast code/product can be adapted to new or unexpected requirements.
- gazelle21 7y ago
  That sounds great but in real life, when your boss wants his crud app fixed yesterday and the previous dev left no documentation for random code, you have to do what you have to do.
ewidar 7y ago
Judging by the rest of the article, I don't think the author is advocating pushing hacks to production. But rather to use hacks to move forward, and then improve once you have a working version.
apotheon 7y ago
Elsewhere in this discussion, I described my first Flux experience. In that same job, the boss decided (after we switched to a pseudo-Flux, Frankenstein's monster of MVC component libs that slowed development to an excruciating crawl) to bring in a consultant to "help". He was the "crap out apparently-working code quickly" brand of "10x Programmer". Some basic functionality for new features got added in a hurry, over a couple weeks' time. The following couple weeks were dedicated to fixing everything he wrote. Yes, I agree: "grown up" programmers think beyond what seems to work right now. Sure, I use dirty hacks semi-regularly, but only when I'm first feeling out how something works. It doesn't last more than a couple hours, usually far less, because the point isn't to commit that code but to learn how to think about the problem so I can do it right, and a "done right" rewrite takes less time to get working than the initial dirty hack. The "done right" rewrite also doesn't impose tremendous maintenance and continuing development costs over months to come the way the dirty hack would. If the author means real programmers use dirty hacks to figure out what they're doing, then they make it right, that's fine. If not, that's not fine at all.

gchamonlive 7y ago

SICP is really cool! I would follow up with Practical Common Lisp right after, for insight into a more usable Lisp dialect.

brunoamuniz 7y ago

"Get uncomfortable" is one of the best advise in anyones life =P stay out of your comfort zone. Also teaching something is a good way to learn more and more about an specific subject