I’m optimistic for interactive and physical programming to take a foothold in our world. How many more phone apps do we really need? Aren’t many of the user optimized social apps wreaking havoc on the youth?
Shifting thinking back to extending human creativity and making programming available to less technical audiences might change our technology use to a less neck craning, social interaction devoid format.
These things take time and significant breakthroughs. See - https://www.lively-kernel.org. Over a decade ago Dan Ingalls and team built a Smalltalk inspired JavaScript flavor. IDE and language combined.
That has morphed into lively.next which is used by at least one commercial company to develop animated visualizations.
I hope to see this type of programming expanded. I had a SMART board in middle school - think figma on a big white board - and teachers came up with lots of creatives ways to engage us and get us to work with each other through doodling on the board.
Will that reach the professional world? Can NASA doodle a spaceship to the moon? Maybe with AI tool development, the idea of computers filling in the technical detail for user drawn plans isn’t impossible.
I started using Wundergraph as a backend service for our recently launched platform in February of this year. I found the usage to be simple and easy to understand, but development and deployment was rough at times, earlier this year there were bugs on some of the common use cases. The team has been very responsive and those issues have been resolved.
Two major changes have pushed this framework into a really mature place. One was a recent rewrite around custom resolvers, which allows for adding business logic in between GraphQL calls. The other is going fully open source.
Despite some initial challenges with the framework, I can't deny that Jens understands the problem domain probably better than anyone else in the world. Glad to see so many issues like authentication and API interconnectivity solved in a production ready way. I'm getting out of the box functionality that I used to depend on entire teams for. The depth of auth implementation, from one line config of Auth0 all the way down to per-operation RBAC is the shining example of how well this framework is architected.
Can't wait to see the continued development and growth from their team!
This is a very small project I built last year called Compute. It's a svelte app with two math visualizations, one for Ulam Spirals and another for Game of Life. I'm looking for suggestions on math or physics concepts that would be fun to visualize or animate. If there's anyone looking for a project to contribute to I've just made the repo public https://github.com/rwest202/compute.
I really like how they have opted to make small changes gradually. Look at the feature lists here https://m.mediawiki.org/wiki/Reading/Web/Desktop_Improvement.... There's a detailed explanation for why each change is being made complimented by a GIF showing the side by side difference. I've been working on an SPA with a tight deadline and we are building new pages almost every other day. It's nice to see a project take a slow and careful approach.
Albeit a now invisible knob that must be searched for via a door scan. While I don’t personally switch my ssh port from default, I would imagine doing so would cut down on a ton of the noise from lowest common denominator ssh attempts.
I have changed some default ports and seeing the number of connection attempts drop from <many> down to close to zero was just nice. There are just fewer connections opened, fewer logs to analyze and so on. In my view, fewer connection attempts means less data to analyze which in my view is a security and cost benefit.
Oh, I had some trouble wrapping my head around the idea. The older people count out slowly by as much as 40 seconds. They are inferring that the perceived time for the older folks is faster.
The article is wrong. From the book itself: "The older group, ranging in age between sixty and eighty, were off by forty seconds. Not far off, but if we were to extend the counting for, say, one hour, it would amount to more than thirteen minutes."
That's 30min + 13min.....they are counting slower....not finishing the task faster...
This is really, really bad advice. Mutiny is hardly an answer to the problem here. It will certainly temporarily avoid the problems you face but if you are a member of a team and this is truly how you act you will get chucked out very quickly. But since you bring up a few of the issues you are facing it's important to address them. I want to focus on unit tests to start.
When I started my first programming job a couple of years ago I joined a team that demanded 100% code coverage. I hated them so much. I was still learning the ropes at this company and I only saw the unit tests as a barrier to getting my work done and earning my paycheck. My first solution was to create bogus tests that always passed. That was quickly discovered and I was reprimanded. My second solution was to get colleagues who shared my hate for unit tests to approve my PRs before they were reviewed by my team. That too was thwarted.
Then one day I was working with a teammate on a new feature and we discovered a bug. He quickly opened up a test file and wrote a unit test, then he went tried a couple solutions until the test turned green. Then he looked at me and said, "When when you are working in a pile of crap, testing makes you feel more confident about your code." That was my first insight into the value of testing. Eventually I came around and stopped trying to avoid tests. I just did the damn work. Once I established trust with my teammates they began to let the pressure off my PRs and slowly the displeasure of writing tests went away.
You pointed out a few different coding practices that frustrate you. And to be honest, those coding practices are not the gospel and should be deployed only when truly needed. However I think you have a serious problem with what a lot of us call being a good teammate. At the end of the day your goal should be to get the product shipped, once you focus on getting your features out the door, unit testing and pull requests become minor details in that process. At the end of the day those are just a cutesy to your teammates to show them that you are willing to be a responsible and helpful team member. Stop trying to fight everyone so much and maybe you will enjoy your job a little more.
I've recently started doing that and it's been a breath of fresh air.
I don't really like the stuff I work with, which is services. I think I've become good at it given the feedback I get from my peers every review cycle, but I really don't like it.
I felt burned out for a long time because of that.
Recently I've simply been doing what I'm interested in, in my spare time. That's learning about embedded systems, something I had an interest in in college but never pursued a career. And for fun, tinkering with old stuff that makes me nostalgic. I spent this last weekend coding in Pascal and messing around with FreeDOS :)
It's hard to do just the fun stuff because that's not what makes good software. It's the unit tests and pull reviews and such that make the software reliable and covering all the niggling edge cases. And that ultimately is what makes a piece of software good.
Not so sure about that. Unit tests and pull reviews are stopgaps so that you don't have to hire 1000x engineers just to get some work done. The true masters of this craft may not need those things
Believe it or not "all the edge cases" can still be perceived by the right mind. It's just that we as an industry have done seemingly everything we can to push those folks out, just look at OP as an example
I've supported ten-digits-per-year (non-SAAS) businesses without unit tests or code reviews and oftentimes deploying straight to production. As the sole SWE for my codebase. Supporting hundreds of remote installations with nothing more than SSH tunnels relayed through an ancient, colocated linux box. And the software was very good, didn't ship with many bugs (and when it did they got fixed real quick), and there were never any catastrophic, non-recoverable issues, nor ever any questions on the integrity of the system or my reporting. We were never seriously hacked (to our knowledge). Crazy times... not sure I would do it again, but.... it can be done.
My first dev job we did most of our work in vim sessions on the development server, and more than once I was asked to hotfix live code running in production. Through the grace of God and an abundance of caution nothing ever seriously blew up as a result of all this madness. (Though, ask my boss about the time he tried to move our MySQL instance onto some very early SSDs) Again, it can be done. I'm sure most of the old hats lying around have tons of stories like this.
If your expectations are not shipping with many bugs and avoiding serious blow ups then yes that's a fine way to do things. And if we're happy relying on a single SWE (what happens if you get hit by the proverbial bus?) then yes that's fine too. And if we never need to scale then SSHing into 100s of boxes is fine too.
Most of my job is replacing stuff like you describe. And it's definitely not fine. Nobody knows how it works because that single SWE is gone. It can't scale with the business and it's a huge drag on productivity because nothing can change without a massive testing effort to ensure it's not broken.
Agreed, but who can you really get mad at? The lone, inevitably overworked SWE that was asked to shoulder the entire burden of the business he worked for? Or management, who most likely denied that SWE the support he wanted?
In my last job I'd advocate tirelessly for unit tests, code reviews, all that. And it was always denied. Ironic given that the other engineers I worked with were MEs, who had notebooks full of processes describing how they were to work so that engineering issues would be caught. But the software? "I don't care how you do it, just ship the feature"
As an aside, I've always found "nobody knows how it worked because XXXXX is gone" to be kind of funny: the code knows, so go read the code. It'll mean everything takes 100x longer but the knowledge is there.
> In my last job I'd advocate tirelessly for unit tests, code reviews, all that. And it was always denied.
My approach to that is to not ask, just write the unit tests anyways, ask a peer to code review without management permission, etc.
We are professionals. Part of that responsibility is to know the best practices for our craft and put them into practice.
We also need to be good at getting the requirements from the technical and non-technical people we work with, and being able to show consistent, incremental progress, and a willingness to quickly change direction when the requirements change.
But we do not need to get input or permission for the process we use to produce those results.
> Agreed, but who can you really get mad at? The lone, inevitably overworked SWE that was asked to shoulder the entire burden of the business he worked for? Or management, who most likely denied that SWE the support he wanted?
There are plenty of SWEs that just don't know any better. I know because I was one of them while writing a lot of software for a business.
I don’t really expect just to do the fun stuff at work, but modern technology seems to progressively burn me out more and more.
I was drawn to software at a time when it seemed like we had control over things. With the advent of the cloud I feel like that control keeps slipping away more and more. Kubernetes is my new nemesis. I seem to be in the minority that perceives it as unnecessarily complex for most tasks. Someone once commented here on HN that the k8s trend made them think people are trying to pretend their code doesn’t run on hardware anymore, and that really resonated with me.
> I seem to be in the minority that perceives it as unnecessarily complex for most tasks.
My boss recently introduced Kubernetes to our software deployment.
The first thing he said, though, is if you don't absolutely need Kubernetes, don't use it. It is extremely complicated and finicky and difficult to deploy correctly, and can bite you in subtle ways.
Then he went on to describe, for our problems, how Kubernetes was absolutely necessary to scale without constant manual intervention and configuration and deployment processes consuming our time.
I appreciated that he had thoroughly thought through the problem before adding more complexity.
I do think there are options to achieve all of that - scale without manual intervention, etc. - without Kubernetes though. At least where I work, if I look at the deployment issues we have, those are all the product of bad decisions and lack of action due to higher priorities. There's no reason why there couldn't be more automation. They're building something new on Kubernetes which looks promising (though I really hope that as an app developer I don't have to think of Kubernetes things, which just irk me), but the current platform would work well too if investment was made into automating the parts that aren't automated.
You don't have to always cover all the edge cases. If you write software for fun, you can often just bake-in assumptions and neglect a lot of edge cases.
While I dabbled with python and Delphi for a bit,my first real development was on Salesforce platform with their proprietary language called Apex. The first thing every developer learns on thos platform is that your code has to have at least 75% test coverage before it can be pushed to production.Testing was inevitable and ultimately part of anything I had to write. With time,I started reading more and more about development, tried different languages and etc.It was really fascinating to read how a lot of people hate testing or teams skip them if the deadlines need to be met. What testing taught me is that if the test is hard to write,it means that the code is crap.Every time I wrote some quick hack,it used to take me 10 times longer to write unit test.
Short version: you find very small things that you can write tests around (pulling messy logic out into testable functions, writing tested utilities that replace dirty hacks, etc.) and start building your testing framework starting with that.
Long version:
Working Effectively with Legacy Code
Book by Michael C. Feathers
It’s almost always bad as a new guy to come in and start refactoring.
There are lots of weird if checks to deal with a vendor that returns bad data over the api every Sunday night. Your new clean code is going to crash and burn in all of these cases.
Unit tests are time-consuming and tedious to write, and generally deliver poor effort-per-bug-found except for initial development (especially since they often displace cross-component tests which tend to catch more bugs). And the cases they test simply reflect the prejudices and lack of imagination of the author. A far better alternative IME is to use generative testing (e.g. property-based testing), which automates the tedium of generating test cases, and finds far more bugs to boot. Bonus: you'll understand your code much better after you're forced to identify and formalize invariants ("properties") in order to write your tests!
I think it is excellent advice for someone who work by themselves and try to find some joy in coding after being in a rut. Yes, some conventions do emerge when being in a large team, it is inevitable, but this is not what this guy needs. Git + Trello is enough for personal projects or small teams. Anything else is a bonus or something you will add down the road and that includes testing or whatever other best practices. There are many jobs, especially in a non tech environments where you can be a sole dev or a part of a very small team, real small and mid businesses that generate value and are much more fun to work for for certain types of personality.
Neat, it would be an interesting linting tool to help minify CSS. I was wondering why the pruning tool took so long but I can see they are using visuals to determine if a a style is needed or not. That's a really smart way to do it, I wonder what other use cases there are for mapping visual images to code. This is almost like a selenium test for CSS.
I wonder how broad the definition of effectiveness is in their implementation. The visual method might have limitations, considering that many CSS properties are only "effective" when you start moving/interacting with elements, e.g. resizing the window/elements, or hovering over elements or using other cursor actions.
Looks like good ol’ screen diffing. It may be possible to use heuristics to detect when a rule might be important for layout in other configurations but this is probably good enough for the stated purpose of highlighting what CSS is important for learning.
Shifting thinking back to extending human creativity and making programming available to less technical audiences might change our technology use to a less neck craning, social interaction devoid format.
These things take time and significant breakthroughs. See - https://www.lively-kernel.org. Over a decade ago Dan Ingalls and team built a Smalltalk inspired JavaScript flavor. IDE and language combined.
That has morphed into lively.next which is used by at least one commercial company to develop animated visualizations.
I hope to see this type of programming expanded. I had a SMART board in middle school - think figma on a big white board - and teachers came up with lots of creatives ways to engage us and get us to work with each other through doodling on the board.
Will that reach the professional world? Can NASA doodle a spaceship to the moon? Maybe with AI tool development, the idea of computers filling in the technical detail for user drawn plans isn’t impossible.