Cleanup takes time. No matter if it is refactoring, fixing bugs, updating supporting libraries, adding the proper documentation, or test coverage to your code. There is no way around this.
It will affect your deadlines today, or sometime down the road. The difference is that today, it’s your choice to make.
Thinking that you get away with this is just naive. It just can’t happen. Not unless you give up on the project or decide to rewrite the whole project, which is an entirely different problem.
Balancing the feature and fixes needed with the necessary clean up work is not easy. It’s hard. You are not alone in having to make these choices. Making those calls is hard, no matter if you are the developer, internal or external client, product owner, or even an end-user. The work is needed. Sooner or later, it will become inevitable, and the choice won’t be yours to make.
There aren’t a lot of options other than just “doing it”. Just as it’s not wise to argue the existence of gravity, which you can debate all you want if it exists or not. If you try to debate this, you are going to have a bad time.
It’s been proven time and again that all the money in the world can’t get you off the hook. There are enough examples to go around.
What makes you think you can get away with it? Is it hubris, inexperience, or you get an adrenaline rush from living on the edge? It doesn’t matter. All that matters is that you should figure out a way to do it sooner, rather than later, and make communication front and center since your team, clients, or users need to understand and give you the necessary support.
As a founder you can choose to look at an obstacle as something that keeps you from moving forward (a roadblock), or as something that slows you down for a minute as you continue along your path (a speed bump).
Roadblocks put stress on your mind. Stress on your body. Stress on your relationships. It’s no way to live, especially for folks who are building startups to improve our lives rather than re-arranging our lives around our companies.
This seems easy and obvious, but it’s not.
When you’re in the middle of a crisis it can feel overwhelming and almost impossible to surmount. I always try to keep my head down and keep working the problem.
If working on a problem doesn’t seem to be getting you anywhere, then walk away and do other things.
Let your mind do the thinking in the background. Once you are ready, you’ll come back to solve the issues wiser and stronger. A calm mind will take you further than you can imagine.
…after working through common arguments and misconceptions, such as that the RISC (ARM) instruction set architecture is inherently inferior to CISC (x86), that the benchmarks spruiking excellent ARM performance are inaccurate, that the performance gap is explained by different operating systems, and more, I’ve found that the central claim of these articles largely holds true: ARM processors, particularly those produced by Apple, have caught up to high-end x86 processors in most perspectives of performance.
I am looking forward to two things from Apple this year: ARM based Macs with desktop optimized CPUs and iOS 13 optimizations for iPad, that allows all that processor power to be fully utilized.
Web developers typically use the .dev extension as a TDL for local development environments. Thus when developing a web app, instead of needing to use “localhost” with a specific port, they’d set up the host files to recognize example.dev as the domain for easier testing.
That has worked fine until now, since Google just released the .dev TDL.
It might be time to switch that to a different local TDL, otherwise your local setting could potentially override an actual functioning app or website with your local configuration.
Granted, its unlikely to happen, unless your website uses the .dev extension, yet, conventions are an important part of a healthy development environment.
With an increasing list of TDLs the best option might be to just start using .development or .local until those get snapped up as well.
There are three big things that remain before the first feature-complete build (which will be 5.0a1): searching, the app icon, and syncing with FeedBin.
NetNewsWire got me hooked on RSS over 12 years ago. Now it’s open source and rewritem from scratch in Swift. I have been using the alphas for a while and it’s the same great app from all those years ago. Can’t wait to get the Feedbin sync feature, it’s my preferred sync service.
Apple just sent this email to developers:
Two-factor authentication is an additional layer of security designed to ensure that you’re the only person who can access your account, even if someone knows your password. This significantly improves the security of your Apple ID and helps protect the photos, documents, and other data you store with Apple. For more information read Two-Factor Authentication for Apple ID.
If you didn’t enable two-factor authentication and believe someone else has access to your account, you can return to your previous security settings . This link and your Apple ID security questions will expire on February 27, 2019.
If you are like me and have a main personal account for all your Apple ID related stuff and a separate one for your work email or developer account, you are probably trying to figure out what do if said account isn’t permanently registered on any of the devices you use.
Here’s the simple work around:
- Set up a new user account on your Mac
- Login into your iCloud account tied to the developer account under the new macOS user.
- Activate two-factor authentication and add your preferred phone number s a backup.
- Verify you are able to login into your account via another device or via browser at appleid.apple.com.
- Logout of iCloud account on the temp macOS user and switch back to your main macOS user.
- Delete the temp account and now, you should be able to use the 2fa via the phone validation every time.
Hopefully Apple will soon allow dual Work/Personal accounts within a single device or iOS 13 and/or macOS 10.15. Until then, this work around should help.