This is probably no surprise to most people, but: spaces, emacs, composition, get lots of sleep.

This question is related: hashnode.com/ama/with-james-long-cj5x0mut902fwjpw…

Right now I use React and Javascript mainly. I use redux for the very core parts of my app that load data from the server. I tend to be pretty minimal so after that, it's highly dependent on the app and it's needs and I usually write custom libraries for it, or pick something if it's already good enough.

I've always loved Clojure(Script) but haven't had the chance to work on a project in it yet. And recently Reason has me interested and with all the React support coming out for it that is likely to be my next language of choice.

Easily React, but that's because I know almost every single little detail about React. A startup should focus on it's product and the users its trying to solve problems for and not on the technology. Focus on whatever the founders or current teams already knows so they can be shipping faster.

I got lucky because I started before most of that existed. :) But really, I think create-react-app is a great place to start. It has everything set up for you that you need and you never have to worry about it. Write ES6, explore React, and go from there.

After that you can try TypeScript or Flow. I'd recommend choosing whichever fits the best for your current app. Depending on the libraries you are using one of them might be more supported.

But really, just get started! If you don't know where to start, just load a JS file in the browser and start with vanilla DOM APIs. You will learn a lot and then you can make choices based on that experience.

I would not say that OSS is necessary step to become a good programmer. Many people became excellent masters of programming before open source was even popular. Github and other tools have made it easier than ever to collaborate on work, but you should in no way feel like you need to participate in open source to get some sort of programmer badge.

OSS is a very interesting model, but has some serious problems too. Much of the OSS world runs on nights and weekends (which alludes to what you said), and easily creates guilt for a lot of people.

I wouldn't worry about it. OSS progresses because many people are scratching their own itch and find it beneficial to try to get others to use it, either for personal marketing reasons or because it feels good. If it doesn't fit into your workflow you should not feed bad at all about it. In some ways, OSS is a very roundabout way to do things. It's often more efficient to develop tools just for yourself or your team, or learn from people directly around you, or just hack on super interesting stuff, blog about your results and leave it behind. There's a lot of overhead in OSS.

If you feel like you are challenging yourself over time, that's all you need!

EDIT:

I missed your very last question, about what other ways can you improve. I would say try to put yourself in a position where you are challenged and uncomfortable as much as you can. This means writing code in other languages, and trying to work with a library that you find intimidating. You will learn a lot just through that, and your mind will be open to a lot of new things.

I'm not familiar enough with issues for non-US people, unfortunately. I'm sorry you've had a hard time. I would say that a truly remote-friendly company should not have a problem with that timezone, in my opinion. A lot of companies say that they are remote-friendly but most people live in the same city, and you don't really want to work for them. You'll feel pretty isolated. Aim for companies that already have people spanning timezones.

Keep building up your portfolio and experience though. It's a little more risky for companies to hire remote, so anything you can do to prove that you are worth it would be good.

I think at the end of the day I want to be shipping things to people, and frontend is where you feel that the most. It's where a lot of hard work (from the backend, etc) can be brought together into a real product, and that's exciting. Having knowledge of all the parts of the system helps me build better UIs and understand the tradeoffs (optimistic updating, how to pass data back to the server, etc)

But it's an apt question because I do have a feeling that I might change my focus at some point. I am interesting in machine learning and graphics programming, so we'll see if I can make that into an actual job.

There's also the fact that it's just so practical to work on frontends. There is so much work and good jobs out there. I used to do a lot of graphics development but I wasn't interested at all in getting into the games industry. So part of it is practicality.

Oh sweet! I used to use Scheme. You absolutely could, but the only problem is tooling. When you do anything with compilers or ASTs, there is a lot of boring stuff that you need to take care off, like tracking the original location of the code so you can show nice errors, attach comments somehow to the AST, etc. You will be better off if you choose a language that already has compiler tooling for the language you are targeting, otherwise you will have to rebuild a lot of boring stuff yourself.

Clojure embodies my favorite programming paradigm: functional, immutable, and data-first. "data-first" means that you think a lot in terms of data, and Clojure has a lot of powerful methods for working with that data in really clear ways. You don't write a bunch of classes that have this.state. You just have state and you pass it into functions.

Code that favors immutability is far more robust. I can't stress this enough. Even if need to mutate an array, if I'm doing some complex logic, I will abstract out as much as I can into immutable/pure functions that take small chunks of the array and return new data, and then only at one specific point in the code it will mutate the array with a splice. Being very explicit about where mutation happens makes things a whole lot clearer. Otherwise you don't know when the earth moves from underneath your feet.

My favorite programming language right now is probably Reason because it feels like I'm learning a lot, which is fun. And robust static typing is pretty powerful.

Emacs is my operating system of choice. I spend 90% of my time in it. It's so flexible, and although not very modern, has a lot of really powerful workflows.

It's only me, but I have a few friends that are giving me advice. I didn't really choose to work on it myself, but I haven't found anybody who is the right fit yet. It's hard to find people who have time and interest in this kind of app, and also is the right "fit". If I release this and it actually gains traction I expect to find help, either part-time contractors or something like that, depending on the funding situation.

That's amazing to hear! I am really enjoying it, it's almost cathartic to me. I don't work in an office so for me it's a way to get ideas off my chest, even if nobody is listening. It's recorded so I link back to it, and it's basically a way of lazy blogging.

I was skeptical that anybody would find it interesting, but hopeful it would show that even really experienced people do a lot of dumb stuff. I think there's too much "reverence" for people that seem smart and it divides us too much, when the only difference usually is some people are pretty good at blogging and writing their thoughts out, and there are really tons of smart people that don't give themselves enough credit. I'd love to break this down as much as I can by livestreaming. So thanks for the good feedback!

Just today I googled "javascript removing item from array" because I couldn't remember if there was a better way than splice.

I definitely will be doing it at least every Thursday. If I can, I would like to do it even more often.

To be honest I haven't actually used it on a large app yet. I haven't worked on a Clojure project and I've only done small projects. However, my experience was good, the language is awesome, but when I was using it there was some pain getting it setup. I think that's better now.

See this answer for it's data-first model: hashnode.com/ama/with-james-long-cj5x0mut902fwjpw…

On top of that, it has a really powerful form of objects and protocols, which allow you extend and existing type but the extension is only locally scoped to the current environment. Think of being about to add a toNumber function to the JS String type, but it's only available in file that have imported your extension. It's like a safe way to monkeypatch; it's awesome.

I'm in a cliche in that my dad brought home a computer when I was young and I just started hacking on it. It was an Apple II and back then programming and using the computer weren't that different... it was so easy to start writing code that eventually you just started doing it if you used the computer for any length of time.

The thing that drove it home though was in high school I was super interested in how 3d games worked. I was in awe that computers were able to render games like Doom (the first version) with such a rich interactive experience. I really wanted to know how that worked so I bought a book called "Rendering Real-Time Graphics with DirectX" or something like that. That opened up the whole world to me and I loved programming.

I don't think it's a big problem, but I think it's a problem. A great example is create-react-app. It's definitely tiring to setup webpack, babel, and other tooling just to make a production-ready app every single time. create-react-app completely solves this problem in a way that works for almost everybody, so the fatigue is gone.

People talk about is as if it's some deep cultural problem, but I think that's stupid. Deep cultural problems are very hard to fix. But the things that actually cause fatigue are pretty easy to fix, like create-react-app showed.

Some people just don't like that the JavaScript world moves so fast. That's crazy to me. We are moving forward, coming up with solutions, and exploring everything. Why would we want to slow down? Why would you want to stop innovating?

You don't have to be up-to-date on every single thing the JS world is doing right now. Just pick your libraries and build your product, updating things every now and then when you have time. While there are problems with overhead, complexity, and boilerplate, too many people conflate that with JavaScript's progress, as if they are tired of both. Of course we should solve the former, but I'll never get tired of the latter.

I only used Angular 1 several years ago, so my experience is extremely outdated. I have not tried Angular in it's current form. I think it's great that multiple frontend solutions exist and you should learn whichever one resonates with you at first. Getting productive with one of them is way more important that "choosing" the right one.

You will also learn about all UI solutions as you learn one of them. Many ideas are cross-pollinating, meaning that you will see traits of react/redux in other places and the communities do a good job learning from each other. You will also start seeing contrasts and understand better why react/redux made certain decisions as you hit problems in angular, and understand the the tradeoffs.

Pros:

• More control over your time and what you work on. Outside of client requirements/deadlines, you can scale back work if you want to focus on something else for a while. You can choose different work each time and keep things interesting.

• Meet lots of interesting people. I find networking somewhat enjoyable. I wouldn't want to do it all the time, but I like meeting people and seeing what they are working on.

• No office/team politics or dynamics to deal

Cons:

• No office/team to collaborate with :) Being challenged with social issues is important and it sharpens your ability to communicate and work with people. You have to be really careful not to isolate yourself.

• Variability of money, naturally. You need to track things to make sure you make enough on average

I would only do it if you find networking somewhat interesting and have a pretty strong network to begin with. I wouldn't do it if you don't already have a decent network. You can start that by blogging, going to conferences, and things like that.

That's a great question.

My style is definitely to just start coding. When you are starting from scratch you have very little idea of what the requirements are. If you start building you will run into a lot of things very quickly and learn a lot.

Then, after you've spent some time building out something, you can step back and start thinking about proper abstractions. Here you probably don't want to code but want to outline boundaries and cut the system up into a few large subsystems. You basically go top-down, but only very shallow. Establish the basic architecture, but give room for all of the subsystem to breathe. Those subsystems could be implemented really messily, but be refactored completely later, and if the interfaces are built correctly the other subsystems would never know.

Redesigns need to be evaluated in light of how much money it's going to save the company down the road. You should almost never redesign an entire app. You are losing way too much gained knowledge and that investment will most likely not pay off. But if you have a good enough architecture, as explained above, you should never be forced to redesign an entire app. If you're app is so fundamentally flawed that you need to redo the entire thing, you're in trouble. Usually, you just need to redesign a subsystem, and if you really believe the new design is better, the company should support that because better code, if done within a realistic timeframe, will almost always pay itself back by reducing maintenance costs.

I don't think there is a first project where I felt a big change like that! It's incremental. You gain more and more confidence as a programmer the more you build.

I do remember feeling pretty proud about a raytracer written in Scheme: https://github.com/jlongster/schemeray

I'm just not familiar with it :) It's not one that I go-to to learn right now, but I know it is a great one to learn from. From what I remember I said "etc", meaning it was just an example list. Haskell is a great language to learn from as well.

I think you should sit down with the basic HTML file here:

<!DOCTYPE html>
<script src="main.js"></script>

And just start writing code in the main.js file. Find a really basic problem and try to solve it using the DOM as a UI.

Just starting to work on very simple problems with make you feel more comfortable to tackle bigger problems, and you'll be surprised how fast you'll go. Don't worry about any frameworks or choosing the right library or anything like that. Start getting stuff on your screen and changing it into something that solves something.

Several things, but ultimately I had been at Mozilla for 6 years so that's long enough to start to get an itch for something very different. I'm interested in a lot of things so I was getting annoyed that I didn't have time to pursue them (some of the programming-related, some not).

The team I was on was going through a lot and I got pretty burned out about all the various politics, changes, and dynamics with most of Mozilla. As said in another answer, I don't think Mozilla is bad place and most medium-sized companies are faced with these issues. But the idea of going out on my own was really appealing, with the ability the focus mostly on things I wanted to do.

I'm also trying to figure out the rest of my career generally, so this is a good time for me to work on a lot of different things and try to figure out where I want to focus on next.

I tend to be minimal. Right now I use OSX (macOS, whatever) but I keep looking at the surface laptops and they are look enticing. I'm usually working in Emacs, Chrome, and iTerm2 (although been meaning to look at Hyper again). Emacs is my foundation for everything. dired-mode for interacting with files, magic for interacting with git, and I can run shells within emacs itself (and I usually use CLIs to interact with everything else).

For my personality, what helps me stay productive is minimalism. If I need to I'll even block certain websites to really force me to stay on track. I also think having a few single tools that last over time is better than depending on too many tools that either break or change over time. So I like to master a few things and stick with them.

Not sure what you mean. React and jest are two projects that use it.