Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.
Only if the code base is well tested.
Edit: always add tests when you change code that doesn’t have tests.
Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).
Disagree on this one, even though I can see where you are coming from. I first learnt programming in Java, and it gave me massive problems to understand the structure and typings. Obviously Java isn’t the most beautiful language anyways, but once I picked up python it started to click for me on how to solve problems, because I didn’t have to think about that many things. I could just go for it. Yes, my code was messy in the beginning, but I wasn’t working on any important projects. It was just for fun.
So I think learning how to solve problems is as important as writing clean code. And python really helped me with that.
I’d actually argue Python stops people learning how to solve problems.
I love teaching juniors and have done so for 10 years but I’ve noticed in the last 4-5 years since Python became the popular choice at universities Graduates aren’t learning anything about Static Types, Memory Management, Object Oriented Programming, Data Encapsulation, Composition, Service Oriented Architecture, etc…
I used to expect most graduates to have a mixed grounding in those concepts and would find excuses for them to work on a small UI projects. I would do this as it gets them used to solving a small problem and UI’s give instant feedback. As Python became dominate university teaching language the graduates aren’t spending their time learning Typescript, Angular, HTML, etc… but instead getting overwhelmed by the concept of types.
Those concepts I want them to learn were created to help make solving problems easier and each has their strengths and weaknesses but most graduates are coming through only knowing how to lay out a small amount of procedural logic using Python and really struggling to move beyond that.
Programing is a lot less important than people and team dynamics
Most modern software is way too complex for what it actually does.
Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.
Don’t even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined … but that was wrong. JavaScript is fine, C# is fine … as long as you don’t stop there.
(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney’s first published game, back when Epic Games was called Potomac Computer Systems. It doesn’t have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn’t cause brain damage, no language will.)
Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”. So what if the first language you used required curly braces, and the next one you learn doesn’t? So what if type inference means that you don’t have to write
inton your ints? You’ll get used to it.You learned how to use curly braces, and you’ll learn how to use something else too. You’re smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.
Python is only good for short programs
Python is only good for short programs
Was Python designed with enterprise applications in mind?
It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.
I mean, it’s still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don’t feel it scales that well.
I agree. The GIL and packaging woes are a good indication that it’s range of applications isn’t as extensive as other tech stacks.
packaging woes
My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it’s a worse situation than Java/TypeScript’s.
We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I’ve had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.
For comparison, it took me roughly zero seconds to start working on an old Go project.
Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
Real programmer learned Assembly.
VHDL is a good language.
If you think to be a good programmer, you’re the opposite.
Are you saying the only good programmers are ones who aren’t aware of their worth and think they’re bad?
Nope, my sentence doesn’t involve “think they’re bad”.
Don’t enforce using the same tech stack on each new project. When customer, domain, environment, requirements etc differ, so might the tool suite, languages, frameworks etc
The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.
That really is one hell of a hot take 😀
I for one really love the zoomed out preview on the right that has become popular in recent years.
https://jason-williams.co.uk/assets/img/2020/debugging_screenshot.png
Really hard to do in a terminal. If you have errors you can see very fast where they are located/clustered in the file and can already tell just by the shape of the program where it is.
Another example: GUI color picker directly in my editor as a tooltip above color values in css/html templates.
Another example: inline preview of latex or Template fragments.
When writing software that will be deployed to a production environment, it’s better to slow down and take the time needed to write a higher quality, more durable solution than to rush and quickly kick a product out the door.
I don’t know why this is a hot take, but sometimes it feels like it is.
Even better is to ship small increments often.
Unfortunately in many organisations, leadership doesn’t really understand that instead of reducing quality, scope should be reduced in order to ship faster. And developers rarely have a say in these things.
While I agree that it can be considered a hot take industry wide, I don’t think for most devs that is a hot take, the ones whom I’ve seen ship broken stuff were rushed on tight deadlines and didn’t have the experience/motivation/political capital to fight back on deadlines.
Shorter code is almost always better.
Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.
A nice thing about code length is it’s objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.
It takes a damn good abstraction to beat having shorter code.
I mostly agree with this but more than shorter code I value readability, I would rather take 3 lines to be clear to any developer than use some obscure or easy to misunderstand structure to write it in 1.
I think they didn’t mean how you structure your code but actually precision.
Here you go: https://codegolf.stackexchange.com/
But on a more serious note, I don’t really agree. Writing more code needs to be a conscious choice, but going for the shortest code too often creates a mess. I know, since I was that junior dev who just wanted to get stuff done and I would ignore project architecture in order to have to implement less, like accessing the database in GUI code.
Shorter code with the same amount of coupling between components and with the same readability is always better though.
i used to think like this. nowadays I prefer readability, and even debugability.
sure, I could inline that expression, but if I assign it to a constant with a descriptive name instead, the next person reading that piece of code will not hate me.
Not sure if these are hot takes:
- Difficult to test == poorly designed
- Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
- Which programming language doesn’t matter (within reason), while amount of programming languages matters a lot
Difficult to test == poorly designed
It’s pretty much a natural law that GUIs are hard to thoroughly test.
But does it have to be? I haven’t touched non-web GUIs since 15 years, so my perspective on this is limited. And web frontend is not what I would call a well designed system for it’s current purpose.
I agree with your first point, but pretty strongly disagree with the other two. Code review is critical. Devs should be discussing changes and design choices. One Dev can not be all things all the time and other people have experience you do not or can remind you of things you forgot. Programming language absolutely matters when you’re not the only dev on the team.
Nice, so they are hot takes :D
If the design of a code change is bad, noticing that in the PR stage is not desirable. It should be discussed before someone actually went ahead and implemented it. It can also happen if people misunderstand the architecture, but again, that should be cleared up before actually implementing a change. Code style should be enforced automatically, as should test coverage and performance. Code review is also pretty bad at finding bugs from my experience. That imo leaves very few things where code review is useful that are not nitpicking.
As for programming languages, the amount does matter for individuals and for teams/organisations. A developer who can only use a single language is not very good, and using a many different languages within the same team is not good either.
Front end and back end are different enough that you can really specialize in one or the other. They take very different mindsets. I know how to make css obey, I don’t know how to make sql performant. Its possible to have both, but not as well.
For every front-end dev, you need 3 back-end guys and a designer.
Programmers are not bad at our jobs, its just not a mature disclipline yet.
It’s not mature, because nobody let it mature.
Programming is over 70 years old, that’s not a new discipline. Yet, the engineering in our industry is still abysmal. Countless reinvented wheels, nothing is ever finished, changes happen often enough for the sake of change, not progress.
That’s part of the nature of programming. Half-finished might be good enough. If you’ve made an awesome wheel but I need a kink in one of my spokes and yours doesn’t do that, making my own wheel might be cheaper than modding yours.
OTOH, there’s nothing more frustrating than looking for a particular wheel, finding ten really great ones that collectively have the features you need, but individually aren’t good enough.
To stay in the analogy: usually we just want to transport things from a to b. It doesn’t matter, how we get there. So usually we begin with a road and start to cobble together a vehicle from barely fitting and functioning junk we find on the roadside.
There’s hardly any stable surface to work on. And that’s extremely costly.
SQL is the core language that everyone should be required to learn first and foremost.
You could be onto something. On of my first language was “dBase” (early 90s) which, through it’s style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.
Learning SQL on an enterprise database is what started my journey into coding. It really forces you to think about what you’re doing because of how structured the language is. It’s also very immediate in that you do x and you get y.
It also makes you think more about data models which I’d argue is why we ended up with the garbage that is MongoDB. Developers not thinking about their data and how it relates enough.
For anyone with their rankles up. 99.9999999% of the time you want an RMDBS. That remaining 0.00000001% you want NoSQL. So any project you spin up? Guess what? You want an RMDBS.
Completely agree. I really love SQL, but I hate it’s syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).
Why would I, an embedded developer working on devices with at most a couple of mb of flash, need to learn SQL?
It teaches you to think about data in a different way. Even if you never will use it in your products, the mental facilities you have to build for it will definitely benefit you.
The best codebase I have ever seen and collaborated on was also boring as fuck.
- Small, immutable modules.
- Every new features was coded by extension (the ‘o’ in S.O.L.I.D)
- All dependencies were resolved by injection.
- All the application life cycle was managed by configurable scopes.
- There was absolutely no boiler plate except for the initial injectors.
- All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
- “Refactoring” was as simple as changing a constructor or a configuration file.
- All the input/output of the modules were configurable streams.
There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you’re a newbie, but it was absolutely brain dead to maintain and extend on.
Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I’ve seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we’d casually make the change while joking about it.
It might sound mythical and bullshity, and it wasn’t perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.
That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not “fun”, programming like a cowboy and ignoring the tests is a whole lot of fun.
I never got so far, but had a system built which some parts of what you described. It was incredibly relaxing to develop with it. Our take as a team was: boring is better, we don’t want to be paged on weekends.
