Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

231–240 of 704 posts

Re: Software engineering topics I changed my mind on

#231

Post by kettro »

zbobet2012 wrote: post #207
Shorel wrote: post #204

Earlier quoted context omitted.

Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters. Some people will always disagree about some points. It's in their nature.

I disagree. The best medium is a whiteboard or a blackboard :p. (Really though, something about paper makes me afraid to "commit" things which make the pieces of paper no longer usable. Something made to be erased seems to be the trick for me).

To this end, I have a small, paper-sized whiteboard that I can scrawl onto on hands at all times. I bought a couple packs of the ultra-fine expo markers, and it’s been a boon. Great for quickly noting things down that don’t need to last.

Having both is important, though: you need to be able to preserve the things that matter, that you may need later on.

Re: Software engineering topics I changed my mind on

#232

Post by busterarm »

pseudalopex wrote: post #214
busterarm wrote: post #191

Earlier quoted context omitted.

Free Pascal. That said, I'll use anything in my paid work if the project is interesting enough. Hence the three years I spent writing PHP.

I'm curious. How did Free Pascal make you a better programmer?

Not an answer you'll like, honestly. Turbo Pascal as the first thing I learned after BASIC as a wee youngin'. Mostly it was about connecting young hobbiest programmer me with seasoned professional me.

Basically, sometime's it's good just to kick back and have some fun with your work. Aside from that though, my impressions of the language are that it forces you to be a little bit more organized about everything than C-derived languages. In Pascal, the things that you do to satisfy the compiler are things you can do for anyone reading your code in other languages (not that you would in those languages conventions though...). And other languages do this even better... I wouldn't recommend anyone go learn it unless they had a real business need to.

Re: Software engineering topics I changed my mind on

#233

Post by quelltext »

01100011 wrote: post #81
ng12 wrote: post #61

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let…

In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed. If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in…

This!

Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc.

Yet, the product manager position isn't really staffed, and neither is the project manager one. So, all the additional work beyond design and coding also falls on the owning engineer. And since we are frugal that engineer is happy to get maybe 1 additional engineer assigned to help. But often that one will also have their own project they own or need to prepare for owning.

So the lead/owning engineers turn into mostly product and project managers but are still expected to do the down to earth construction of the product which means to get anything done in the expected time frame engineers need to put in long hours.

I just don't get it. It seems utterly wasteful use of resources. I'm not saying engineers cannot be good at these things, but generally speaking product and project managers cannot and do not need to be able to code in addition to owning a project/product. Adding/hiring more project managers to projects would be the single most effective way to speed up project timelines as it frees the engineers, the producers of tangible product deliverables to focus on that.

In no way do I mean engineers should be cloistered away from dealing with product or project decisions or even chatting with users. But it needs to be in the correct proportion to the actual engineering work.

Add to that the addition of duplicate processes (e.g. we are dealing with 3 right now that cover the same ground but are ever slightly different in what needs to be done to cause triple effort) and everything grinds to a halt. A project manager could also be the right person to push back on management and dedicate resources to improving project management overall.

Re: Software engineering topics I changed my mind on

#234

Post by vmception »

cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

In my own different comment I highlighted the same two points with the opposite conclusion haha!

I find dynamodb to be unnecessary but I prefer nosql systems

Re: Software engineering topics I changed my mind on

#235

Post by potta_coffee »

Nycto wrote: post #193
potta_coffee wrote: post #185

Earlier quoted context omitted.

I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.

The first thing that comes to my mind is that there are different axes that you may need to scale against. Microservices are a common way to scale when you’re trying to increase the number of teams working on a project. Dividing across a service api allows different teams to use different technology and with different release schedules.

I don't necessarily disagree, but I believe that you have to be very careful about the boundaries between your services. In my experience, it's pretty difficult to separate an API into services arbitrarily before you've built a working system - at least for anything that has more than a trivial amount of complexity. If there's a good formula or rule of thumb for this problem, I'd like to know what it is.

Re: Software engineering topics I changed my mind on

#236

Post by cccc4all »

wegs wrote: post #19

I predict the following changes: 1) Typed languages are worse, and you want people with high levels of competence. 2) Java actually IS terrible. You win very little by designing for incompetent coworkers. Plan for competence, and hire appropriately. Small elite teams beat large incompetent teams every time. See #1. 3) Thinking through scalability upfront matters in many systems. Not all systems. Many systems. 4) SOLI…

Typed languages can be better utilized for self documenting codebase. The types are used to show clear intent for the code.

Re: Software engineering topics I changed my mind on

#237

Post by kstenerud »

At year 15 or so, he'll change his mind about project managers.

Project management is one of those broken things in the industry because it's never taken seriously. People promoted to PM generally receive no training or mentorship. In fact, sometimes the only way to break into management is to quit your job and start somewhere else with a slightly exaggerated resume. And sometimes the only qualification required is a desire to give it a try.

So you have an entire class of people whose skills follow what you'd expect in a task with no discipline or training, with 50% of PMs moving the needle in a positive direction, and 50% in a negative direction (to varying degrees like a bell curve). Roughly 25% of them are people you'd actually like managing your team.

Re: Software engineering topics I changed my mind on

#238

Post by tcbasche »

pdimitar wrote: post #223
tcbasche wrote: post #217

Earlier quoted context omitted.

For me that's been Elixir. It's made me appreciate some of the more functional aspects in Python, like generators, map, filter and the functools library in general.

Ironically Elixir has become a personal favourite and I find it amazing for backend web work, especially API gateways -- although it does very well with server-side rendering web projects as well. It's my main work tool (very close second is Rust). But I fully get what you mean. Working with it and learning it has been a very strong eye-opening experience.

I really enjoy the tooling as well. I feel like these days tooling can be just as important as the more “tangible” benefits of a language. The Phoenix code (and test!) generation in particular is just magnificent, not to mention docs. Pythons most lauded doc generation tool Sphinx on the other hand is just complicated and confusing.

Re: Software engineering topics I changed my mind on

#239

Post by t-writescode »

dathinab wrote: post #130
t-writescode wrote: post #49

Earlier quoted context omitted.

My biggest frustration around ‘best practices’ is when you’re tasked with learning a new framework to consider adopting it for the company and you’re given a week and they want ‘best practices’ to come out of it. There is no way I can learn how to write good code in a completely new framework that everyone should model after from that. I can show what worked for a toy problem and something that’s hypothetically simil…

> learning a new framework to consider adopting The best practice is to not learn a new framework. Only learn the new concepts (technical and UX, if there are any) and if there is no noticeable benefit do continue using old framework. In many cases new frameworks do not bring improvements to a degree that switching is worth it. They often do either obfuscate it or don't realize it themself, but most new frameworks do…

In the specific examples I’m thinking of, it’s transitioning from a single-threaded, non-async infrastructure to a multi-threaded and async infrastructure in a new language. We had to learn a new technology stack for that; and, frameworks, among others, are a required step in that.

I’ve also had to do “best practices” around things like introducing grafana or whatever to our stack, and what the metrics should look like.

Re: Software engineering topics I changed my mind on

#240

Post by pseudalopex »

busterarm wrote: post #232
pseudalopex wrote: post #214

Earlier quoted context omitted.

I'm curious. How did Free Pascal make you a better programmer?

Not an answer you'll like, honestly. Turbo Pascal as the first thing I learned after BASIC as a wee youngin'. Mostly it was about connecting young hobbiest programmer me with seasoned professional me. Basically, sometime's it's good just to kick back and have some fun with your work. Aside from that though, my impressions of the language are that it forces you to be a little bit more organized about everything than C…

Thanks!
Post reply on HN