@jlongster
Nothing here yet.
Nothing here yet.
No blogs yet.
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'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.
Great question! I'm currently obsessing over my tomato plant outside and it finally is starting to grow 7 tomatoes. I took gardening pretty seriously this year and next year plan to plant a much larger garden. I installed a drip system so it's automatically watered. I also really enjoy woodworking but don't have a place to do that, but that's about to be solved because I'm getting a workshop built behind our house. Soon I hope to be making tables and other things like that. I would love to be able to draw but I haven't ever had time to really get into that. I feel like that's something I'll do later in life. Recently I've been getting pretty interested in finance and investing too, but that's somewhat related to technology.
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: https://hashnode.com/ama/with-james-long-cj5x0mut902fwjpwtiqsu0ypn#cj62j1ok4008zvmwt58ddjhck 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.
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.
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.