DEV Community: Lenny Cheng

What career advice would you give to your younger self?

Lenny Cheng — Thu, 27 Jun 2019 21:28:42 +0000

Imagine you time-travelled back to the ~~future~~ past and met your younger self.

What career advice would you give yourself? What do you wish you had been told when you started out in the software industry? What wisdom would you share to help your younger self?

Software, Like Money, is Just a Tool

Lenny Cheng — Sun, 02 Jun 2019 02:21:03 +0000

Imagine a civilization that relied on bartering – tit for tat, apple for orange, donkey for horse, food for water. Commerce would be challenging: if you were an apple farmer and wanted oranges, you had to trade them with orange farmers. But if the orange farmers only liked to eat peaches, they would be unwilling to trade for your apples. To get oranges, you would need to first find someone willing to trade peaches for your apples and then trade those peaches to the orange farmers. That’s a lot of work getting oranges. If only there were some easier system of trade!

Oh wait, there is: money! Money is a universal currency that facilitates exchange of goods. Instead of trading apples for oranges, you can trade apple for money (sell) and then trade the money for oranges (buy). Since money is used by everyone, the orange farmers could then use the money you paid for their oranges to buy peach, thereby saving you the trouble of trading apples for peaches

Fundamentally, money facilitates trading and solves the problems poised by bartering. It is a tool to facilitate getting stuff you want or need.

Imagine a civilization without software. There are no cars, computers, phones, alarm clocks, or electronics. Life would be different. If only there were some way to quickly tell a friend to meet up in 5 minutes or to download Taylor Swift’s latest hits. How much easier life would be!

Software (along with hardware and other technologies) solves these problems. It is common nowadays to text a friend to arrange a meetup or to fly across the country to visit a relative. Software has advanced every industry and in some cases, has even cannibalized other industries, such as type writers.

Fundamentally, software is a bunch of instructions telling machines how to solve problems too complex for humans to solve, and in doing so, it augments us to surpass our own biological limitations.

Both money and software exist to make our lives easier. The former increases communication among ourselves; the latter increases communication beyond ourselves. Both of these are tools whose usefulness is determined by the problems they solve.

Money, often represented by coins, is almost useless until society assigns purchasing power to it. Money is used to buy many tangible goods and services but can't buy intangibles. Money can't buy something that doesn’t exist (although it is an incentive for finding new discoveries); it cannot buy love (it sure can buy fake love though); nor can it buy happiness.

Having excessive money isn't the key to happiness; it's simply a tool for getting better physical goods and services. It's sad that many people work tirelessly to earn extra money that they didn't need. The equivalent analogy would be to work hard amassing a huge toolbox filled with tools that will never be used. Yeah, not very useful. On the other hand, although money doesn’t guarantee happiness, lack of money often guarantees miserableness because of the inability to purchase life necessities. It is beneficial to view money not as a mythical substance but simply a tool whose usefulness depends on what it can buy.

As money is a common exchange system for humans, software is a common communication system for machines. Similarly, software, often comprised of thousands to millions of lines of code and is useful only when it solves a problem. Even beautifully written, highly maintainable, and naturally extensible code is not useful if it fails to solve a problem (unless that problem is to learn how to write beautiful code) or if it aggravates an existing problem.

As money facilitates our lives, so too should software. There’s a huge difference between writing beautiful software for the intellectual satisfaction and writing software as a tool to solve practical problems. The former is for enjoyment; the latter is to eliminate existing problems. As such, when writing software, it is important to know if you’re writing for academic/learning pleasure or to solve actual problems.

Seeing software as a tool adds perspective to design decisions. If the tool would be used only once, development speed would be more important than maintainability and as such, it would be better to quickly write bad but working code than to excessively dwell on writing quality code. On the other hand, if the tool will be used by many clients for a long time, writing maintainable code makes more business sense. How we approach software is determined by the problem it is intended to solve.

Money and software are both tools designed to solve problems. On their own, they are not so useful. After all, most people would agree that a phone is more useful than a thousand coins or a million lines of incorrect code. But when they are used to solve problems, they become essential to our daily lives.

This article was written in 2016 at https://lennycheng.com/blog/2016/09/04/software-and-money-are-both-tools/

Thoughts on Programming and Life

Lenny Cheng — Tue, 28 May 2019 20:29:20 +0000

Society has different perceptions on programming.

Some people view programming to be a mystical skill, an esoteric form of knowledge understood only by few. Like a samurai who deftly welds his sword to conquer dragons, programmers weld their unique knowledge to solve enduring problems, such as instant communication and automation.

Meanwhile…

Other people view programming as a pseudo-trivial skill practiced only by those who prefer staring at computer screens than exploring the world. Like a donkey who makes semi-intelligent noises, programmers speak in a blabbering and convoluted language, replacing "Make the program faster" with "Use this lazy-loading singleton to manage a pool of worker threads and then implement a callback function to parse the contents in that ASCII table."

I think programming can be both magical and boring.

I am amazed that by hitting keys on a keyboard, we can invent useful stuff that had never been made before. We can connect humans who live on different continents, initiate awareness and social change, and automate tasks that would otherwise have taken years to manually complete.

In software, the sky is the limit – wait, spaceshuttles use software too, so instead let’s say, “In software, the laws of physics are the limits” (one can argue that the machine running the software is the limit). Compared to other technologies, like the level or the wheel, software is young. But in a short 70-some years, it has become one of the building blocks of every developed country. Software enables us to build machines that evolution never prepared us for: we can leave this planet, explore the oceans, and see microscopic organism. Software is a tool for achieving more than what our biological selves can achieve on their own.

I am equally amazed that many "keyboard operators" have become so addicted to typing on a keyboard that they forget there's more to life than programming. They've lost track of the bigger picture. Under the excuse of writing better code, we might neglect our health, let slide our dynamic dreams, and lose perspective on the trials and successes of our communities.

Living a wonderful and meaningful life includes more than just communicating to machines: it is also about fulfilling our personal needs and desires. We want the liberty to pursue our dreams, to explore what exists beyond our personal worlds, to develop meaningful relationships with others, to be in good health, to laugh and have fun. Ironically, software developers sometimes act like robots programmed to build software!

Software development is a huge topic that contains many subtopics. Some of its subtopics include:

various types of development (web, embedded, systems, applications, defensive, network, etc, many of which work with each other)
programming paradigms (the style we write code, eg, assembly, procedural, object-oriented, functional)
development methods (how to split development into various stages, eg, Agile, XP to maximize productivity)
relationship between code (yes, like humans, code is often interdependent and we seek to build robust relationships that don’t need to constantly change when requirements change. Design patterns and refactoring techniques are helpful)
problem solving (how to accomplish a task efficiently. To solve problems, one must first understands the relationship between codes and then think. Algorithms and data structures might be useful for hard-card problems)
programming languages (there are dozens of major languages. Eg, C++, Java, SQL, JavaScript

Software development is not only about writing code but, like all team projects, is also about solving problems that affect other humans. As a result, software development links well with:

business (if others are purchasing our software, it is important to understand how the business process works)
communication (we want to inform our intended audience about what we’ve built and why it’s important as well as understand customers’ needs)
teamwork (since software is usually written by teams, we wish to maximize productivity)
education (the software industry rapidly changes. Developers are usually learning new techniques and we seek to quickly learn and apply new knowledge)
industry knowledge (if we’re writing software for medical equipment, it makes sense that we have a basic understanding of what the equipment does)
creativity (there are many ways to write code. We also decide how to balance time complexities, space constraints, deadlines, various possible designs with and human factors)

Writing software is more than simply staring at a screen and typing. It’s an intellectually stimulating process that uses, logical reasoning, creativity, and thoughtful perspectives to solve meaningful problems. Software development combines with almost any discipline to complete tasks and increase productivity. As long as we bear in mind the bigger picture of our software and why we’re building it, I think developing software is a fun and meaningful practice/hobby.

This article was written in 2016 and first appeared on my blog at https://lennycheng.com/blog/2016/02/27/thoughts-on-programming-and-life/

Web Development: What Users See vs What’s Really Happening

Lenny Cheng — Mon, 27 May 2019 03:20:12 +0000

What we perceive to be happening is often different from what is actually happening. For example, it appears like Joanna is effortlessly acing every interview but actually, behind the scenes, Joanna tireless prepares many hours for every interview. It might seem like Sam is a naturally gifted programmers; behind the curtains, Sam actually reads about programming during his spare time.

Back when I was developing web applications, I noticed that users' perceptions of how a web application worked was often different from how it actually worked. For example:

What user think is happening: We click on the close button and the popup is gone.
What may actually be happening: An event handler hides the popup element so that it is no longer visible but still exists

What users think is happening: As we scroll down the page, images and text fade into existence, appearing to be loaded instantaneously
What may actually be happening: As we scroll down the page, the opacity of the images that already been loaded on the page change from 0 to 1

What users think is happening: Each tab has different contents and they appear to be loaded when a new tab is pressed
What may actually be happening: The contents to the tabs had already been loaded and clicking on a tab displays its associated content and hides the other content

What users think is happening: We click on an image and the screen becomes larger
What may actually be happening: An HTML element resides underneath the image so that when we click on the image, the underlying element is clicked on, which then causes the screen to become larger (the distinction is that the underlying element is causing the screen to become larger, not the image)

What users think is happening: We type information from one page that is then displayed on a second page
What may actually be happening: The client posts the information to the server, which stores it in a database. The server then returns a new page along with the information the client had posted to a new view.

Knowing the difference between what the users see and what the source code actually does enables a developer to optimize their application. For instance, if we were to programmatically close the window, we can either programmatically hide the window or trigger a close action, which would then hide the window anyways! By knowing how the code works, we can solve a problem directly from A-B instead of A-X-Y-B. Taking the longer route may not affect much the performance of a project but it will increase the amount of time to maintain or scale the project whereas taking the direct approach, A-B, decreases unnecessary code and increases the project’s maintainability.

What the users see and what the developers see can be different. The former sees the GUI, the shadow of an elephant; the latter sees the source code, the elephant itself.

This article was written in 2016 and first appeared at https://lennycheng.com/blog/2016/02/11/web-development-what-users-see-vs-whats-really-happening/

C++ Templates and Java Generics: Two different approaches to generic programming

Lenny Cheng — Mon, 06 May 2019 22:25:10 +0000

Intro

Generic programming is the ability to abstract away concrete types and was first introduced in the 1970s. It facilitates code maintenance, reduces redundant code, and enables optimizations. Rather than writing the same algorithm again and again, but with different data types each time, the programmer only needs to write it out once. Eg, defining size_t sum(T) rather than three definitions for size_t sum(int), size_t sum(long), and size_t sum(double).

C++ allows generic programming via templates, which were included in the 1998 standard but had appeared years earlier in The Annotated C++ Reference Manual. Java allows generic programming via generics, which was introduced with Java 5 in 2004.

Two Different Design Paradigms

They might look similar on the surface but have contrasting design paradigms. C++ templates uses code generation whereas Java generics uses type erasure.

Type erasure removes the type of an object and adds a cast in the compiled bytecode. It doesn’t actually add anything new to the language. For example, as described in Java Generics and Collections, the bytecode of

List words = new ArrayList();
words.add(“Hello”);
String s = (String) words.get(0);

and

List<String> words = new ArrayList<>();
words.add(“Hello”);
String s = words.get(0)

are identical! This is curious, if the syntax is so different, why would the Java committee decide they should output the same bytecode? After all, it seems like inserting a cast and removing the type would prevent potential optimizations.

The alternative is for generics to introduce different bytecode. However, code that uses generics and compiled with Java 5 would no longer be compatible with code compiled written without generics before it. Businesses that were already using Java would be hesitant to migrate to the newer version. Type erasure was a compromise between business needs and language enhancements.

Type erasure also ensures that there would only ever be one implementation of a generic type. For example, List<String>, List<Integer>, and List<MyClass> all have the same implementation of List.

Contrasting this with C++ templates, which was included in the standards from the beginning and uses code generation, vector<string>, vector<int>, and vector<MyClass> each has its own implementation. Although this may increase the size of each translation unit and the final executable, implementation-specific types offer the programmer greater flexibility, including:

Specialization of template functions and classes to enable optimizations. An example is vector<bool>, which is a space-efficient version of vector
Creating member variables of the same type. In Java, type erasure makes is almost impossible to instantiate a variable of the type, such as T[] t = new T[10]; In addition, static member variables can’t refer to a generic type
Static polymorphism, such as STL containers and using typedefs to make generic operations, such as using iterators
A lot of complicated stuff like policy traits and meta-programming, which can compute prime numbers at compile-time!

The impact of code generation vs type erasure affects the performance and readability of the languages. While templates offer more flexibility to the programmer, they’re harder to use because of tricky rules that cause inconvenient bugs. Also, nothing’s quite as dry as reading cryptic error messages that span hundreds of characters.

To briefly summarize, C++ and Java have different models to enable generic programming. C++ uses templates and code generation whereas Java uses generics and type erasure.