|
Most people are adding specifics, I want to start in the abstract and move to concrete, mainly to address principles that influence my concrete choices. Bare with me for a paragraph or two. Ideally, I think we can agree (if we don't please inform) that if we could snap our fingers and have an app that the client wanted that would be preferable to making one for, say, six months. If I had to snap twice I'd do that too. If I had to snap ten times that also wouldn't be so bad. For a week worth of snaps it would be boring but hey, six months work in a week? Why not. If we agree, then we're following the path of least resistance to our goal. We want the greatest reward for the least work. Value to cost ratio as close to infinity as we can get it. What that means for software development is that when I hit one key, I want an app to appear. If not an app than a service. If not a service than a module. If not a module than a file. If not a file than a snippet. If not a snippet than a command. The most code, the least amount of typing (ie, work). As little guessing, wondering, searching, typing and thinking as possible. As little work as possible. Everything straightforward, familiar, routine, and simple. For me, this becomes a process of planning, study, action, reflection, measurement. Write your expectations and designs (very high level), google around and see what you can find. Implement. Periodically reflect on your implementation and measure yourself and your work to find inefficiencies, process, and habits that can be improved. I like to use a Pomodoro to keep track of my time and how long it takes to do certain things. If something is taking time I keep a record of it and use my record as a baseline, then I experiment and see if changes I've made to my work produce better results. Here are a few concrete things to consider: - Take advantage of sharing (google, check product hunt, look at Awesome lists, aws, etc). Don't re-invent the wheel. - When green-fielding, Code for as long as you can before you start testing. This is especially true if you're running your code on an emulator (like a mobile app) and it loads slowly. If you make heavy use of mutations and side effects this might be difficult, so try to make your functions stateless and self-contained. It limits the scope of your error to a smaller service area. - If you're building an app from scratch for a client, consider learning a design took first and getting that stuff out of the way early on without having to code. Framer, invision, adobe xd, and sketch come to mind. - Compilers are your friend. If you use a language that has a good compiler, you can catch many errors as soon as you save the file. - If you're doing visual work, live reloading is your friend, especially for styling. If you're using component-based libraries for the web (React is great), you can get a lot done quickly with Storybook, which allows you to isolate individual components and work on them without having to interact with the whole application. - When you create a project, rely on templates like create-react-app. - When creating files and functions, also rely on templates and snippets. - When editing code, personally nothing beats Vim keybindings. Great for combating repetitive strain too. I find I code slower but get the same amount of work done. It's great on the arms. - Use an ide for autocompletion, snippets, debugging and the like (if you prefer text editors, you can usually get language servers, snippets, and debugging ui as plugins. Even for Vim or Emacs). - use a debugger - USE A DEBUGGER - For backends, services and frameworks go a long way (PHP/Laravel, Python/Django, Ruby/Rails). - Mouseless navigation with vimium is beautiful. - if you're a Linux connoisseur, and you're really digging the mouseless thing, I recommend i3. Great, simple, tiled window manager. |