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.
Programing is a lot less important than people and team dynamics
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.
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.
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.
Most modern software is way too complex for what it actually does.
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.
My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.
After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.
Amen. I once had an interview where they asked what my skill is with .net on a scale of 1 - 10. I answered 6.5 even though at the time I had been doing it for 7 years. They looked annoyed and said they were looking for someone who was a 10. I countered with nobody is a 10, not them or even the people working on the framework itself. I didn’t pass the interview and I think this question was why.
As a hiring manager, I can understand why you didn’t get the job. I agree that it’s not a “good” question, sure, but when you’re hiring for a job where the demand is high because a lot is on the line, the last thing you’re going to do is hire someone who says their skills are “6.5/10” after almost a decade of experience. They wanted to hear how confident you were in your ability to solve problems with .NET. They didn’t want to hear “aCtUaLlY, nO oNe Is PeRfEcT.” They likely hired the person who said “gee, I feel like my skills are 10/10 after all these years of experience of problem solving. So far there hasn’t been a problem I couldn’t solve with .NET!” That gives the hiring manager way more confidence than something along the lines of “6.5/10 after almost a decade, but hire me because no one is perfect.” (I am over simplifying what you said, because this is potentially how they remembered you.)
Unfortunately, interviews for developer jobs can be a bit of a crap shoot.
They wanted to hear how confident you were in your ability to solve problems with .NET. They didn’t want to hear “aCtUaLlY, nO oNe Is PeRfEcT.”
Yeah, I mean no shit, with hindsight it’s obvious they were looking for the 10/10 answer. I was kicking myself for days afterwards because that’s the only question I felt I answered “wrong”. Tech interviews are such a shit show though that you can start to overthink things as an interviewee. Also, an important aspect of the question that I didn’t mention was they specified “1 is completely new, and 10 is working at Microsoft on the .net framework itself”. The question caught me off guard. I have literally no idea what working at Microsoft on the framework is like. In that context being a 10/10 felt like being among the most knowledgeable person of c# of all time. Could I work on the framework itself? Idk maybe, I’ve never thought about it, I don’t even know what their day to day is. I should’ve just said 10/10 though, it was a dev II position to work on a web app, it wouldn’t have been that hard.
10 is working at Microsoft on the .net framework itself.
An interesting spin. I like to imagine that you could have answered “10/10,” taken a pause, and declared that you’re leaving the interview early to apply directly to Microsoft to “work on the .net framework itself.” 🤓
dev II position to work on a web app
”we want you to tell us that you’re over qualified for the role”
Understanding how complex something is, is irriversible. Once you reach that plateau you will always know how much there is you don’t know.
Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.
Using dynamic languages is understandable for a lot of language “external” reasons, just that I really feel like there’s no good argument for it.
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”.
The amount of unqualified people is staggering beginning with those who have no university education.
There are also a lot of e-commerce agencies who just don’t have their sh1t together. Was expected to work on 3 different clients a day who all had different platforms, different requirements etc. Yes, you can dump some new code into the project that looks like it’s working, but then you don’t have time for any unit tests, exception handling if the user won’t cooperate etc. and it’s basically just some dodgy, untested code that will come back a few days later with some issues related to something nobody told you about.
The other “senior” programmer in the company never set up any local environment but instead ftp’d all changes directly to the live server. I asked him if needs help to set up a local server and debugger, but instead he would just dump vars on the live server and stream the contents of error.log to his second screen to catch any issues…
Go with what works
Error messages should contain the information that caused the error. Your average Microsoft error “error 37253” is worthless to me
Keep functions or methods short. Anything longer than 20 - 50 lines is likely too long
Comment why is happening, not what
PHP is actually a really nice language to work with both for web and command line utils
Don’t over engineer, KISS. Keep It Simple Stupid
SOLID is quite okay but sometimes there are solid reasons to break those rules
MVC is a PITA in practice, avoid it when possible
Keep functions or methods short. Anything longer than 20 - 50 lines is likely too long
If it doesn’t fit on my screen it’s too long.
PHP the language has become pretty nice, but I recently had to work with a PHP CMS deployment, and it was an absolute pain to do. PHP frameworks seem to still exist in a world where you manually upload code to a manually configured server running apache. Dockerizing the CMS (uses Symfony) is/was an absolute pain.
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.
We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they’re absolutely necessary or if they’re very focused and don’t try to do a million things. It’s not about size but complexity.
I also feel better when I use less libraries, even if that may seem irrational sometimes.
I think part of the library craze stems from people who really only want to use the programming language as a tool to get fast results (which is legitimate, of course).
For example in academic contexts you have a lot of scientists who use R with a whole truckload of libraries, often unnecessarily. It reminds me of the plugin craze in the whole wordpress can of worms…
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.
