Programming

If I can code doesn’t mean I know how to do X thing on your stupid phone

It's not magic

That a "working" prototype with no tests is just as good as a carefully-designed and well-tested feature. I see this happen so often that a coder puts a prototype in front of a product manager or exec and they are like, "this is exactly what we need, now! Ship that!" And then misery ensues for all of the engineers that need to maintain this piece of garbage. As managers pressure the engineers to build new features on top, they inevitably break fundamental parts of it, and without a confident leader to demand that tech debt is paid off, that product will consume the souls of many desperate coders.

In contrast, if you do it right the first time, there will be significant parts of code that never need to change, and the parts that do need to change will be much easier, because it will be obvious if it breaks the tests.

Myth: code can be ugly as long as it works, don't spend company time on making it look good or on minor optimizations.

The truth is that you can tell when effort has been put into a job. Even if it just works, the lack of discipline means that in the end it will be difficult to maintain and probably will fail in unexpected situations.

Every language has its conventions, but if I spot more than a line of separation between blocks of code, that is a common telltale sign of noob. Run from that shit.

That “just changing a word” is easy and quick. A codebase is an iceberg. Management only really typically understands the surface, but there is a disproportionate amount of ice under the water.

I had to change all instances of a label from a word to an abbreviation. Because we don’t have i18n set up in the app, it ended up affecting 55 different files. I did my best to consolidate into everything calling a common function, but it’s far from perfect. 55 files changed because management said “oh this word here should be shorter”.

Myth: software engineers replicate value similar to a factory worker making the same item over and over

Truth: software engineers are closer to artists than factory workers IMO. We find and create new value, not replicate existing value

Technical Leads are not rational beings and lots of software is developed from an emotional stand point.

Engineering is trade offs, every technical decision you make has a pro/con.

What you should do is write out the core requirements/constraints.Then you weigh the choices to select the option that best meets it.

What actually happens is someone really likes X framework, Y programming language or Z methodology and so decides the solution and then looks for reasons to justify it.

Currently the obvious tell is if they pitch Rust. I am not saying Rust is bad, but you'll notice they will extoll the memory safety or performance and forget about the actual requirements of the project.

You NEED to be good be in math to program.

Whilest for some highly specialist fields you definitly do, but for a lot of jobs things don't get more complex than calculating averages.