Regardless of tech and challenge-specific context, what overarching principles do you come back to?
For further actions, you may consider blocking this person and/or reporting abuse
Regardless of tech and challenge-specific context, what overarching principles do you come back to?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (36)
For me, I often go back to this Alan Kay quote:
To me it basically describes all great software.
Less code is more ☺️
Slow down, take the time to do things right. You'll end up going faster in the end.
Numerous projects I've worked on with this in mind seemed to have really slow progress in the beginning, but really fast progress towards the end. In all cases we've always hit our initial timeline goals, but exceeded expectations on follow-up work.
That is indeed a good approach but as I had experimented in a lot (too many for sure) of organizations, you are too often force to rush on things because of business deadlines, promises made (not by the devs) to the upper management, and the list could go on and on.
So if your Product Owner, Stakeholders, etc... are not from technical background you are going to have a hard time.
So I found it very useful to make quick Brown Bag Lunch open to everyone, so that anyone, from technical background to marketing etc can join, have fun and have a better understanding about what it takes to develop something. But as it is not the end, debug it, test it, deploy it, etc...
It is very helpful for everyone. And then if everyone speak a common language it makes things easier and we can tend to take the time to do things right so that we can go faster in the end.
Yeah and do TDD.
I disagree with TDD. Sure write tests for your things, but TDD is just kool-aid that caught on in early 2013. Academically it makes sense, but in reality it's not practical.
With my limited experience, I'm trying to teach my clients that "rushing" the developer isn't the greatest experience. For me, quality is better than speed, and taking the time to correct errors and improving the code is time well invested.
First and foremost for me, understand who wants what, and why. Take it slow and steady, I'd rather take 10 extra hours and have it "perfect(1)" than skip 20 hours and only half work. Don't write sixteen layers of abstraction, you'll give yourself and other developers a headache; if you don't need it, don't do it. Finally, take 30 seconds and write a comment somewhere about why you wrote that file/line/n... etc, it saves time for future developers not having to guess! Nice to have for me is a "maybe later" - it'd be nice to have a lot, but let's focus on what we need to have
(1) perfect, understanding there is some minor bugs, but the functionality is implemented to the best of my ability
I'm getting better at writing comments and commit messages about the why. The how is in the diff :-)
Real developers ship. Sounds elitist and I can't even remember where I first read it, but it's a really nice principle to follow.
For me it's -
Refactor when it's necessary. Don't delay it, otherwise the codebase will keep on increasing and will become unmanageable one day.
Understand the customer's actual problem, not the request specs.
Organization is hard and important to get right, so invest effort into it. When you put something in the wrong place it creates non-trivial, unnecessary overhead on future work. This applies to architecture, lines of code, and even the company itself. This is why "refactoring" (reorganizing) is important. Otherwise, the effort of overcoming disorganization eventually dwarfs forward progress. Aka "technical debt", only it is not really technical.
Production code is the only code you can count on. When it is in production, you have a feel for how much it costs to operate and maintain. Until then, it is guesswork and you cannot rely on it. As much as is possible, focus on releasing features incrementally to production instead of going dark for long periods of time. For new projects, deploy something simple and iterate. Building something complex to start is a losing proposition... unless you already have working production code you can use as a template.
Invest lightly in technologies but heavily in skills and understanding. Techs come and go constantly. Knowing a framework inside and out may be entirely wasted effort after a few years. But skills and logical concepts can serve you for many years to come. In practice, this means I prefer simple libraries where usage is obvious instead of frameworks with lots of abstractions. This also informs my preference for functional programming, because abstraction is minimized, and if you want to get into abstractions, they are based on provable/reusable mathematical properties... not some random opinion of the language/framework writer.
Be good to work with. You will never succeed without the cooperation of other people. There is no point in fighting this inevitability. Instead, work on improving yourself so that you can make the best of it. I am deeply introverted, so if I can learn enough to get by in this area, I know you can too. That classic book How to Win Friends and Influence People is a great starting point.
Premature optimization isn't just about speed/memory usage - it covers things like abstraction or thinking ahead for potential features, too. As Sandi Metz says:
Obviously with features it gets tricky - you don't want to create a program that's hard to extend to add new things later! There's a lot of nuance involved, which brings me to my next point...
Don't be dogmatic; context is everything. Sometimes TDD is the right decision, sometimes it's not. Sometimes switching the team to deploy on Docker is the right decision, sometimes it's not. Sometimes rewriting a component in Rust is the right decision, sometime it's not.
A lot of blog posts don't cover the context behind the decision, which is like doing math problems without showing your work. And a lot of hard decisions never end up solidified in blog post form, because communicating that nuance and context is really hard!
This is something I've seen in a lot of blog posts recently (such as those written by Ted Kaminski), and I'm glad. I wish I had links to each of the ones I've read discussing this, but they're kind of hard to find in my history!
This is so true. Every year we developers come from our favourite conferences and are so geared up to completely rewrite our apps. Whether it was (or is) SOA, NoSQL, microservices, you name it, we jump the bandwagon without thinking whether we really need the technology. Just because Google/Facebook/Netflix/Spotify is doing it, doesn't mean you have to.
The Commandments of a Great Frontend Developer