Invariably, good enough is better than perfect. Indeed, good enough is often better than ideal.
Because the good enough solution gets you to ship NOW. The ideal solution keeps you in a holding pattern until YOUR criteria are met, not your Customers.
Good enough leads to results that you can act on and learn from. These results provide actual data that you can use to inform your decisions and THEN allow you to work on what your ideal outcome is.
I’m reminded of a talk that a Game Developer gave. He mentioned that he read the source code of the game Doom and saw that they used a very simple algorithm for loading map data. He raged that they should have used proper Software Development principles and advanced Data Structures to load and save the data. He set about to show them how right he was by implementing his own vision of what the code should look like. He found that his code was not only slower, but harder to understand and didn’t work very well. He also understood another concept very clearly…
The author of the code he raged against drove to work in a Ferrari, was worth millions of dollars and released many successful games while he was just someone on a mailing list complaining about his “simplistic” code…
He never forgot the lesson that often, good enough IS ideal.
I was perusing courses on Tutsplus, Pluralsight and a couple of other sites as well as my daily dose of Programmer-centric newsletters and something caught my eye. I noticed that Functional Programming was a sort of common background noise throughout.
I vaguely remember mention of it back in my days in College and University but nothing substantial. The one thing that I remembered is that it’s a very old concept, dating back to the 60s and 70s.
Now, this probably doesn’t strike you as interesting and it doesn’t really to me either. However, it’s been a theme that I’ve noticed with other concepts as well in Software Development. A while back (60s and 70s), Functional Programming sucked and Procedural Programming was the best. Then after a while, Procedural Programming was garbage and Object-Oriented Programming was the way to go. Now we seem to be going back to Functional and maybe Procedural.
I watched a talk on Microservices and I found this to be a part of this resurgent theme as well. Essentially, Unix is a bunch of little programs or, in some ways, a bunch of little Microservices. But as companies grew and computing became more complex, big Monolithic systems were THE WAY TO DO THINGS.
For what my opinion is worth, I recommend just focusing on the fundamentals. I try to learn how things work (Browsers, languages, data structures) at a fundamental level and fill in the gaps as needed. This idea recycling has me feeling exhausted.
This is an issue I ran into on my Windows machine. Some of the files in my node_modules had filenames that were nauseatingly long. This causes an issue
with git where you get the error: “Error: cannot stat filename too long” or something to that effect.
Here’s how I fixed it. Run the following in your terminal:
git config –system core.longpaths true
I then made sure that the node_modules directory was not in the Git repo:
git rm -r –cached node_modules
I then added the node_modules to my .gitignore file.
Hope this helps!
This post from John Somnez caught my eye:
In his post, he addresses an email from one of his followers asking “why does Programming suck?” I was taken back by this question. It’s something I’ve asked myself a lot over the years, but due to my insecurities I felt that maybe I just wasn’t good enough to do the job. Over time I’ve seen this question pop up again and again. There was even a talk that I watched delivered by Thomas Figg describing the horrors that he has experienced in the Industry. In a way, I felt vindicated. I felt that the responsibility had been lifted from me. The responsibility of trying to become better as a Developer and a Communicator. “Of course it’s not me, the Industry just sucks.”
This ties into a point John Somnez makes about why programming sucks. The constant pace of change in our Industry. He argues that professions like Electrical Engineering don’t change very much over time. A circuit is a circuit. In some ways I agree with this, but my gut feels differently. In some ways, this is true. However, in the beginning of Electrical Engineering, there were many new ideas being introduced. For example, Alternating Currents (AC) was first utilized in the 1850s which was incompatible with the infrastructure that Edison had setup based on Direct Currents (DC). It was adopted after much resistance (pardon the pun). Today, Electricians are the practical application of Electrical Theory and have reliable and standardized tools to allow them to perform their work.
My personal feelings on the matter is that programming sucks because of a lack of standardization. In the early days of my career doing Web Programming, MVC was not a widely adopted way of structuring code. In fact, every project I took on seemed to be a snowflake. Each one was coded in an entirely different way. Although WordPress, Drupal and Joomla were starting to come into their own at the time, custom web applications simply followed the Architecture of least resistance. Want an SQL query displayed directly to the user? Sure! Go for it! The aforementioned CMS’ as well as CodeIgniter and Zend Framework did much to remedy this and today I would be hard pressed to find a PHP project that was built without the use of a CMS or Framework. It seems like we have come to some sort of standardization when it comes to MVC. However, we still have a long way to go in my opinion.
The next domain we need to standardize is that of the Front-end. This is something I feel we as Developers need to do more to solve. Take jQuery for example. Yes, it has weaknesses and drawbacks. But think of the benefits it offers. I can select an element and change its color if I wanted to in one line of code! I did Front-end development for a time before jQuery existed. If you haven’t done that then compare it to writing Assembly code in some regards. The DOM combined with Browser compatibility issues ensured that the most trivial tasks would take about a full day of work with enough defensive programming checks and if/else statements to make you feel like someone suffering from Clinical Paranoia. jQuery comes and takes a lot of that away. Were Developers happy!?! No! We needed it to be more lightweight which led to the birth of Zepto and other variations because Developers can be an arrogant bunch. We see something and think it can and should be done better.
Developers need to be comfortable with the idea of Tradeoffs and we need to be better at communicating to our Stakeholders and our Clients. We also need to promote the idea of “the right tool for the right job.” To further riff on this idea, I recently worked on a Ruby on Rails project. The site was basically a CMS and even included a Blog, User Management, etc. However, it was coded entirely from scratch and making any changes to it is perilous because there is no testing and the original developers are long gone. My contention was that Ruby on Rails wasn’t even needed for this. Yes, you are probably screaming a list of Ruby CMS’ into the screen right now. However, I would argue that this was a perfect job for WordPress! WordPress had a lot of the desired features right out of the box and millions of plugins available. But, because the original Developers were Rails Developers, they wrote it from scratch. If all you have is a hammer, then everything is a nail as they say.
To conclude, my answer to the question of why Programming sucks is that it is because of us. Because of Developers. Our natural inclination towards trying to improve tools by writing new ones makes it much harder to standardize our tools. We can’t blame our Clients or Stakeholders for our misery because they trust us to weigh the pros and cons of our tools and proposed solutions. They don’t understand our problems and they certainly can’t adapt their goals and expectations unless we explain it to them in a clear way.
This is an older article I bumbled across on the InterWebs but one that I feel still rings true unfortunately.
While I do encourage you to read the article, I will summarize and weigh in. The fact is that Software Development is really really hard and a lot of times it’s really shitty. What do I mean by that? Several things which I will cover briefly.
First, the methodologies available to building Software products are still new. While methodologies like Agile are helpful, they are by no means a silver bullet. The advent of Test Driven Development (TDD) and Acceptance Testing is making a difference in the quality of code being produced, however, there are still a large number of Developers and Companies who have not adopted these concepts. Along similar lines, much of the legacy code still out in the wild was not developed using TDD, so trying to implement it into these projects is incredibly difficult. Although Ruby on Rails has lead the charge of using TDD in the web development space, much of the way development works on the web doesn’t make doing TDD easy. For example, it’s difficult to test things like Async calls, etc.
Second, many of the tools Developers use are simply broken. I just spent the better part of 5 hours of my own time in last night trying to get a unit testing library working with my Android Project. It required reading a nauseating number of posts all of which contained several uses of the word “hack” in their instructions. I couldn’t imagine going into surgery and listening to the Doctors talk about how they had to hack together a device to perform Laparoscopic Surgery on me and feeling very confident. How about a Carpenter that has a broken level or a Drill that overheats and has a short in it?
Last, our methods of managing Software Projects can sometimes be compared to an ADHD seven-year-old’s Birthday Party. Chaotic doesn’t even begin to express some of the projects I’ve been involved with. In these projects, several priorities were changed back and forth, and were often dropped entirely due to poor communication, etc. As a side note, the word “priority” was never meant to be pluralized and only recently in history have people started using it in the plural form.
To summarize and paraphrase the article (again, I really encourage you to read it), Developers are treated as little more than manual laborers. That is, management is under the assumption that to increase productivity in a project you can just add more Developers to decrease the amount of time it takes to complete said project. One way which was, and still is in some cases, to outsource the work to places like India and China where you can get people to work for you for very little money.
This is a question I see over and over again that seems to spark a debate amongst veteran Developers. It is a valid question in my opinion. When I started Programming in the early 90’s there wasn’t a lot of options available to you. I started with Visual BASIC because it was the only book at my local library targeted at teaching Programming to kids in an interesting way.
The first programs that I wrote were barely programs at all. They had no graphics and you could only use them in the Command Prompt. The reason why I took an interest in Programming was because I wanted to learn to make games. Although I wouldn’t get into programming anything graphical until much later, my games ranged from “Guess My Number” to a Battleship-ripoff to my “Magnum Opus” which was a text-based Adventure game.
The reason I rambled on about my early experiences with learning how to program was to illustrate a point. I didn’t set out to specifically become a C Programmer or even a Visual BASIC Programmer. I had a problem to solve: I wanted to make my own Computer Games. The reason why I picked Visual BASIC was mostly out of necessity, but also because it helped to achieve my goal faster and in a more direct way.
If I had picked up a book on C++ or Assembly language, I would have spent an inordinate amount of time learning and figuring out the minute details of how Computers work and use memory. More importantly, my 9 year-old brain probably wouldn’t be able to stay interested long enough to finish a game since I would be spending time debugging and fixing memory leaks.
To come to my answer to the question of which is the best programming language to learn first after a long-winded discussion I would say that it’s the wrong question to ask. Even if you know you want to be a Developer, learning a Programming Language is and end in of itself. The better question to ask is what problem do I want to solve?
I’ve been working on some Rails stuff on a fresh Ubuntu install and came across this issue when trying to install Rails. I get the message “zlib is missing necessary for building libxml2”. Here’s how to fix it:
In the terminal run the following command:
“sudo apt-get install zlib1g-dev”
After that it installed properly and I was able to continue on my merry way!
I’ve been working on a Mobile App that I am hoping to release to the App stores shortly. One of the things I really wanted to get right from the beginning was Marketing. By training, I am a developer but I have picked up some Marketing skills along the way. One of the biggest mistakes people make with Mobile Apps, or any product for that matter, is not thinking about marketing from the beginning.
One of the most important things you can do for your Mobile App is to perform App Store Optimization. Like Search Engine Optimization (SEO), App Store Optimization (ASO) relies a lot on picking the right keywords to rank for. Unlike SEO where you have access to a lot of public data, the App Stores are really secretive and don’t release any data on search volume or similar data.
There are formulas you can use to estimate search and download volume. Fortunately, there are some folks who have done all of the work for you. I researched some different ASO tools and the one I will review in this post is one called Sensor Tower.
My purpose for using Sensor Tower was twofold, the first was to see if there was enough searches to make developing my app worth the cost. The second was to see which low competition, high traffic keywords I could rank for. A nice side-effect was that I could see other relevant keywords that I didn’t think of.
The first thing I will note about Sensor Tower is that I thought the User Interface was really clean and well organized. I didn’t really get stuck anywhere nor did I have to look up any tutorials or videos. I was able to jump right in and start using it. One thing I liked, which is a nitpick, was that when you click on an App that appears in the list of Apps that are ranking for a keyword, it opens in a new window. This is nice since I found that I had six or seven on the go and didn’t have to click the back button all of the time.
Because this is pre-launch for my app, the most useful tools for me were the Keyword Research, Keyword Rankings, and Keyword Suggestion tools. My strategy was to think of as many keywords as possible, and add them to the Keyword Rankings screen. Then I would drill a bit deeper and look at the Keyword Research tool to see what other related keywords existed. Last, I would follow that up with the Keyword Spy tool which looks at what keywords your competitors are using and what they are ranking for.
My one caveat with Sensor Tower was related to their Android rankings for keywords. The competition for any keyword was very high. I might have missed it, but I was unclear as to what their sources were, meaning do they just use Google Play or do they also include the Amazon App Store and the others that exist for Android?
My one critique didn’t make the tool any less useful and I still gained a lot of insight using Sensor Tower for the ASO process. The biggest thing I learned is that, aside from keywords being huge in your marketing success, there are lots of low-competition and high-traffic keywords that I can rank for. The process overall gave me a deeper appreciation for marketing and promotion.
I came up against this issue recently. The only thing I had to do was update Titanium to the newest version and it worked like a charm!