I work at a small organization where code reviews are good, but I’ve noticed that the larger the code review, the faster it needs to get done in order to avoid merge conflicts, which means large code reviews are much less effective in proportion to the size.
I’ve noticed that the larger the code review, the faster it needs to get done in order to avoid merge conflicts, which means large code reviews are much less effective in proportion to the size.
Exactly. And in larger corporations where you have many people contributing and the code is moving fast, having people nitpick your PRs just for show is crap because it delays everything sometimes by days. I had to say no very clearly to some people on code reviews because they were demanding me to place variables in alphabetical order on hard PRs that took quite sometime to get working and were very prone to code conflicts.
Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.
Story time.
Once I worked with a developer that just joined the company straight out of college, and had far more ambition than competency. That developer decided that code reviews where the venue where their high bar for code quality would shine, so they decided to nitpick everything that went against their poorly formed sense of taste. As luck would have it, the developer was assigned to a legacy project that was in cold storage for years and had no tests and linters, and was in a really poor state, and proceeded to leverage that to challenge each and every insignificant detail such as if a space should be at the left or at the right of a symbol. Each code review automatically received dozens of comments nitpicking whitespace changes. What a waste of time with so much noise.
I drop by the project, and noticed the churn that developer alone forced upon everyone, as that team had a rule that all code reviews should be passed by all reviewers and that reviewer made it their point to reject reviews that didn’t complied to their opinion on whitespace. So the first thing I did was onboard a code formatter, and made it my point to subject the spec to an unanimous code review. That problematic developer made it their point to nitpick away each and every single setting, but it turned out some of their opinions conflicted with previous feedback.
So the code formatter tool was onboarded onto the team. Did that stopped the problematic developer from continuing their nitpicking? No. Except this time around other developers started pushing back because the opinions were contradictory and contrasted with the official code formatting style.
All it took was a couple of days for the problematic developer to go from dozens of comments per day to zero. The code formatter was still optional and not fully adopted, but the problematic developer simply ceased with the bickering.
I wish this had been my experience. I pushed for so long in my last company for standards to be written, code formatters implemented and objectivity to be brought to reviews but it was always ignored.
Instead I had to endure every employee who claimed seniority (in a non hierarchical company) subjecting their opinion on style in reviews. It came up the point that I dreaded having to work with specific people because they kept triggering my PTSD with their moving target of micro management.
Only afterwards did I truly appreciate how poor a lot of their opinions were. Now one of my first questions when approaching a new project is what standards we’re following. If they look at me blank faced that’s a pretty solid red flag.
jQuery was an essential stepping stone back when JS was lacking a ton of features that people take for granted these days.
Sure everything could have been done with Vanilla JS but it was verbose and difficult to follow. jQuery made it possible for any developer to quickly make a page dynamic
Having fun when programming should be much more important than having correct or fast code when you’re a programmer and should be what we should aim for first.
Having fun when programming should be much more important than having correct or fast code (…)
That’s only remotely reasonable if you’re a weekend warrior that messes with coding as a pastime. Even so, I’m not sure what fun you can extract from dealing with slow, broken code.
Of course those concepts are intertwined in some way.
But as a full time lead dev of a relatively big project, I find that a lot of people, often junior devs, concentrate a lot on what they think is “good code” and not a lot on whether they and other devs are having fun. It may make sense when you’re junior and you have to learn a lot at once, but when you’re experienced enough I feel that focusing on having fun, both for you and your team, should be much more important to us than focusing on precepts you read on having fast code and theoretically clean code, as long as it doesn’t lead the code to be less fun to work with in the long run.
For example, doing R&D re-implementing things from scratch, in most cases just to throw away the great majority of it, could be considered as fun by most programmers, even when it makes not much sense because what you did before also worked. As with switching some architecture around (perhaps wrongly, but it’s hard to know sometimes before you tried it).
I’ve come to very much dislike scrum or agile management as well due to all its protocols and the ways it enforces a certain way of progressing (with tickets, progress reporting, mostly short-term work) which focuses on the project’s goal (which really is what the company wants), sometimes at the expense of devs experimenting and just having fun (what I advocate we should aim for). Though it all depends on your project and company I guess.
It can be rewarding. For me, this has a lot to do with team culture. Am I supported and given the time needed to make improvements as I go or am I constantly rushing to make a deadline?
So much. When I’m trusted to find the right balance of productivity and quality, I enjoy the work more. When I enjoy the work, I’m more productive and write better code. It’s a positive feedback loop.
I have a good one that’s guarenteed to blow up my inbox 🎣
People who put the title of “architect” in their tech job titles are stealing valor from actual architects, and clearly doing it bc it sounds cooler than “software designer” or “coding technician” or whatever the more boring and appropriate job title would be
This is now endemic in every field, not just the tech sector, and its largely thanks to the widespread use of the term “architect” in tech
Middle-managment banking position with slight kickbacks? Please, no, I’m an “Investments Architect.” Me? No, no - I’m not just some chemist working for a shitty soda company, I’m a “Beverage Architect.” And so on
I just put “software engineer”, or “senior programmer”. It’s all the same to me.
Software Architect is an altogether different thing, although in my career I’ve had to do a bit of it, it was never a principal task. And these days that job is often driven by “Tech Director” or “Tech Lead” or the 20 other titles that don’t mean that much.
After 15 years as a “Programmer” , I’ve done architecture, design, programming, instrumentation and iteration, integration, build management, team management, and lead/director tasks. Don’t care what my title is, just pay me what I’m worth, and let me code.
Programming is actually hard af to do for any extended period of time (more than half an hour)
It requires such a specific mind that’s drawn to all the detail oriented specific robotic parts of coding but almost all coders say coding is easy because the people whose mind don’t fit coding already quit long ago
Yes I find coding hard and no I’m not coping
Actually programming being difficult might not be correct but more like programming is largely unbearable
Stick with it. Programming takes a long time to learn - and I don’t mean the fundamentals; I mean there’s so much to the job that just takes experience to pick up.
After a while, you can pick up a problem/feature, dive into a code base and instead of becoming lost, things just slide into place in your brain and you can focus on the problem/feature rather than having a whole bunch of non essential stuff stuck in your head.
And the secret to getting there is simply wanting to understand. Don’t be satisfied with knowing that you fixed a problem, make sure you understand why your fix worked. Don’t sweat the bigger picture, just focus on each task. And get good at debugging early, that helps soooo much.
The people who say coding is easy do it because it does become easy eventually and then eventually you forget how hard it was in the beginning. It’s also a lot easier if you find it fun and can practice in an environment where you don’t have crazy deadlines to meet and have a good teacher or mentor who is willing to help along the way.
All conventional wisdom and many teachers of mine have told me I should be brilliant at programming cause I’m smart, good at math, good with computers etc.
But I’m sloppy with details and can’t think robotically.
We spend too much time focusing on the wrong skills in coding
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.
I don’t agree and I don’t disagree, but I thinkcontext matters a lot here. Some teams and codebases need deep knowledge, some don’t. Some nned sql performance, some don’t. Your conclusion is only true some of the time
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.
Files are a mistake and destroy all structure information.
You don’t have guarantee nobody touched your file, we should database that keep structure information instead.
Command Line is the minimum effort human interface, if we had more time/skill to make interface, the cli wouldn’t exists.
You don’t have guarantee nobody touched your file, we should database that keep structure information instead.
What is your definition of file and database? For example, do you think SQLite is a database, and a SQLite database file counts as a file? Do you think that editing SQLite or PostgreSQL with a third party client counts as touching a file?
If programmers stick to what they know and not try to solve every problem at hand with the latest thing/programming language they’ve learned then there would be fewer bugs and projects would end by the estimated dates.
I think failed estimated dates just highlight how much we don’t know about ourselves, our systems and our own knowledge.
It is the abyss of the unknown talking back to us. We have the privilege of having the stuff we don’t know thrown back at us to prove us wrong. And we often fail to be humbled by it.
Much of the job is dealing with the unknown. A surprise in scheduling can either shorten a task or lengthen it. It can’t be shortened past the time it takes to recognize it’s finished, but it can be lengthened indefinitely.
Most technology, programming languages and frameworks feel just the same, in a professional environment. Majority of web and apps is so simple that literally anything will do. Simple api consumption, simple database crud stuff. The tech stack doesn’t matter that much.
My crazy take is that there needs to be a interpretative language alternative to Python which uses brackets to define scope and/or things like elif/else/fi/endif/done. Much easier that way in my opinion, and the “;” shouldn’t be necessary. I’m used to Python, but if I had another language which can be used to serve similar purpose to Python with those features, I would never code in Python again when it comes up.
Having to code in Julia and G’MIC (Domain-Specific Interpretative language that is arguably the most flexible for raster graphics content creation and editing), they’re the closest to there, but they’re more suitable for their respective domain than generic ones.
Ruby does that (well you use the keyword “end” instead of a bracket) but it fell out of favor before it got as big as python, to my knowledge, because of worse multithreaded performance in comparison (which I think has been fixed) and a bias towards unix systems over windows
Python is legitimately the best language by far for the vast majority of non-performance critical tasks, and most tasks that need to be developed for are not performance critical.
Oh man, I actually like the language, but you made me think of my own hot take:
Python has inexcusably poor docs.
Just a smattering of examples, which aren’t even that good, while failing to report key information like all the parameters a function can take, or all the exceptions it can throw. Any other popular language I can think of has this locked down and it makes things so much easier.
For bigger projects, anything with MANDATORY types is a must for me. Optional, not compiler checked hinting doesn’t cut it.
Not that i hate the language, but I do hate the tooling around it. I don’t think I’ve ever had a pleasant experience with setting up a Python project. And all the data stuff is just wrappers for code in other languages, making the packaging story even uglier, even harder.
You’re right now to compromise on this, but you can give yourself mandatory types in Python, using MyPy, if that’s your only issue with it.*
Because you don’t need elegant subprocess handling, intuitive reliable logging, and don’t mind needing a to autonate a linter to check for whitesoace bullshit.**
**Python is my favorite language, actually. Really.
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.
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.
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.
Yeah the error list is my friend. Typos, assigning something to the wrong thing or whatever is fixed without having to run the code to test it. Just check the error list and fix any dumb mistakes I made before even running the thing. And I can be confident in re-factoring, because renaming something is either going to work or give a compiler error, not some run-time error which might happen in production weeks later.
I do believe that static typing is at least a local optimum, but I am still not entirely convinced. Rich Hickey is a very convincing presenter and I can’t help but think that he is on to something — with Clojure the chosen direction is contract-typing, which is basically a set of pre- and post-conditions for your functions that are evaluated at runtime. Sure, it has a cost and in the extremes they are pretty much the same as dependent types, but I think it is an interesting direction — why should my function be overly strict in accepting a “record” of only these fields?
Add comment