1. 50
  1.  

  2. 9

    Glad to hear you are doing what you enjoy and getting paid for it. The industry definitely needs more dedicated, self-directed people.

    I’m curious to hear about your experience with writing for DigitalOcean? Have you just applied and got accepted? What is the process like?

    You should learn about algorithms and datastructures though: it’s not just helpful, it’s also a very interesting subject.

    And so are types: a good type system is really about expresiveness with automated checking rather than just the compiler preventing you from doing things it thinks make no sense. Languages with modern type systems like PureScript or Elm are gaining popularity in the JS ecosystem, and some classic languages can be cross-compiled to it: Facebook Messenger is written in OCaml for example. For a teaser: in https://perl.plover.com/yak/typing/notes.html there’s a live example of type checker finding an infinite loop.

    1. 8

      Regarding DigitalOcean, they found some articles I wrote on my own site and asked me if I’d be interested in writing for them, so I agreed to do the “How to Code in JavaScript” tutorial series. As for algorithms and data structures, (and types) I am interested in learning them; they’re on the top of my learning in public list. I’ve been playing around with TypeScript as well, to get familiar with more strict typing.

      1. 5

        I started learning typed languages with Elm and I found the experience really nice, even though I eventually “outgrew” it, mostly due to lack of interesting features and feeling like it’s kind of a dead end.

        OCaml/ReasonML is great but not very beginner-friendly atm, though the community is growing and doing a great job at making it more approachable. TypeScript also has a lot of good points, but I don’t think one can use it to its full potential without “being immersed” in a fully typed language first.

        So I definitely recommend Elm if you wanna get started with types and all that, but I wouldn’t invest on it for the long term.

        1. 1

          I was considering learning Go to get more familiar with a typed language.

          1. 13

            Go doesn’t really have much of a type system… If you’re mainly looking to learn Go by all means do it, but to really learn typed languages I suggest you look elsewhere.

            1. 4

              Go types aren’t really anything to write home about, and there are special rules for builtins that you don’t get to use (and therefore learn about) properly. If you’re comfortable with JS, I’d suggest TypeScript. You can add it one file at a time, and it’s easy to tell it to shut up and trust your word if you’re doing something magic it can’t grok, or you’re just mid-way through converting a module.

              1. 2

                Go’s approach to interfaces are pretty uncommon and worth understanding.

                1. 2

                  I agree on both counts. Doesn’t make Go a good place to start getting a handle on typed systems in general though, IMO. And to me, the most interesting thing about Go interfaces is the “static duck typing” aspect, which is exactly how TypeScript interfaces work, and is why you can migrate to TS a module at a time, using module-private typedefs even for inter-module communications. TS will happily let you do that, and still tell you when your structures aren’t compatible, which means you don’t have to have a single source-of-truth for any system-wide object shapes until you’re ready to do so.

              2. 2

                A quick example. In Go, the usual approach to functions that may fail is to return a tuple of error value that can be nil and an actual value.

                err, value := doThings();
                if err != nil {
                ...
                }
                

                The caller must always remember to actually check the error.

                In ML/Haskell, where you can have a “sum type” that can have multiple variants carrying different values, there are types like this:

                (* 'a and 'b are placeholders for "any type" *)
                type ('a, 'b) result = Ok of 'a | Error of 'b
                

                You cannot unwrap an (Ok x) without explicitly handling the other case without getting glaring compiler warnings (that you can make errors):

                let result = do_things () in
                match result with
                | Ok value -> do_other_things value
                | Error msg -> log_err "Bad things happened"; do_other_things some_default
                

                If you have a bunch of functions that may return errors, you can sequence them with a simple operator that takes a value and a function (the function must also return the Ok|Error type). If the value is Error is just returns it, but if it’s (Ok x) then it returns (f x).

                let (>>=) x f =
                  match x with
                  | Error _ as e -> e 
                  | Ok value -> f x
                
                (* if at least one of these functions returns Error, res will be Error *)
                let res = do_risky_thing foo >>= do_other_thing >>= do_one_more_thing
                

                (Note: OCaml also has exceptions and they are used just as widely as this approach, Haskell uses this approach exclusively)

            2. 2

              That learning in public list is really cool, what an awesome idea. Also, thanks for sharing this article :)

            3. 1

              I’ve been trying to learn more about expressive type systems as opposed to compilers complaining about nonsensical code.

              Could you please recommend some resources for further reading?

              1. 2

                “OCaml from the very beginning” is a very nice book, and it’s not very expensive. For the non-strict way, http://haskellbook.com is good, but expensive.

                If you want something free of charge, it’s a more difficult question. Stay away from “Learn You a Haskell”, it’s a very bad pedagody. Robert Harper’s “Programming in StandardML” (https://www.cs.cmu.edu/~rwh/isml/) is great and free, but it’s in, well, StandardML, the Latin of typed functional languages. You will have no problem switching to another syntax from it, but while you are in the SML land, you are on your own, with essentially no libs, no tooling, and not many people to ask for help. Tutorials on https://ocaml.org are good but not very extensive.

            4. 6

              I have a pretty similar story with a backend focus. Throughout high school I taught myself the basic CS fundamentals. I had taken the MIT OpenCourseWare course on algorithms, as well as a number of other courses. To give you an idea I had completed ~200 problems on Project Euler.

              When I graduated high school in 2015, I had taught myself roughly the first two years of a typical CS curriculum. If I went to college I would spend the first two years covering stuff I already knew. The topics I saw after those first two years didn’t appeal to me. I think it was worth it to spend four more years in school to learn about those topics and get a degree.

              Due to my algorithms knowledge, I had an easy time interviewing with companies. I eventually found my way to Heap. When I joined Heap, I knew next to nothing about databases. I could explain to you what a join was, but had never performed one myself. When I joined Heap, they made me the person who was working on scaling Postgres. Since Heap has a large Postgres cluster with 100s of TB of data, I got to learn a ton about how to optimize and scaling Postgres. Initially I was the only person focused on scaling Postgres. After about a year a database team was formed and I soon became the leader of that team.

              In April, I left Heap to use my Postgres expertise to start a business. I started Perfalytics which was recently backed by YCombinator. Right now we are focused primarily on providing tech support for Postgres. A lot of teams are using Postgres, but aren’t sure how to solve performance issues as they come up. We advise these companies as they scale. Overtime we plan to automate ourselves away by building tooling that would give the same advice we would otherwise give.

              1. 1

                We advise these companies as they scale. Overtime we plan to automate ourselves away by building tooling that would give the same advice we would otherwise give.

                Love the idea. There’s a lot of people in mid-sized to big companies that do that for their own jobs. Gives them more fun time. ;)

              2. 7

                Thank you for this write-up. It’s inspiring to see how other people have entered software development.

                It reminds me of why I think that training for some careers in software development should follow an apprenticeship model rather than the traditional academic degree path. Some careers do not need the “formal” knowledge that is often covered in advanced CS courses. Bootcamps have filled this space but some of them have sketchy practices.

                1. 3

                  Really happy to hear about unique backgrounds like mine being successful. It’s a nice break from the “BS in Computer Science from {Yale,Harvard,MIT,Berkeley,Princeton,etc}” homogeny that was so prevalent in San Francisco when I lived there.

                  1. 3

                    As someone with a traditional CS background from a non-Ivy League school, I’m glad more people are calling out non-traditional routes to success. The prevailing attitude of “only the skills matter, but if you have a degree from a prestigious institution, then that’s better” should be called what it really is: credentialism.

                    I don’t have a big problem with it, as crappy as it is, if companies would admit to it. But they won’t.

                    1. 1

                      It’s a tough line to tow, for sure. As an industry, we’re terrible at interviewing and sometimes its easy to go with the “safe” option. From the cold, purely capitalistic standpoint of a company, I think it makes sense to go with safety.

                      This, of course, ignores the socio-political reasons of why certain people go to nicer schools than others, equal access, etc.

                  2. 3

                    I also have no degree, but I attribute my success, such as it is, to being in the right place at the right time – I went to Chicago intending to become a computer scientist, but dropped out in 1992 after my second year, and walked right into the beginning of a career that, in retrospect, looks a lot more intentional than it was.

                    1. 2

                      Wow. You’ve accomplished and learnt so much! I’m definitely bookmarking this post and I hope to work through and learn a lot from your journey.

                      Thank you for posting. Very inspirational!

                      1. 2

                        The top paid developer in our company doesn’t have a degree, nobody cares about a piece of paper if you’re good at your job.

                        1. 6

                          The problem is often getting in the door in the first place without one.

                          1. 2

                            This is a dangerous meme. The average non-degreed developer earns less than a degreed one, so at some point it does matter. Your person at your company is anecdotal and, unfortunately, not representational.

                            1. 2

                              Yeah. I’m not saying I’m unique in this regard, just making a list of everything I did and learned to get there so other people entering the industry can get an idea of what they might need to know or want to learn.

                            2. 1

                              As another programmer without a degree I really like seeing this documented. Thank you!

                              1. 1

                                This is so cool, floppydiskette! I wish more people did write-ups like this. =) I am now inspired to document my own.

                                1. 1

                                  Awesome! Always interested to see the journeys other people have taken.