Engineers should focus on writing(yieldcode.blog)
yieldcode.blog
Engineers should focus on writing
https://www.yieldcode.blog/post/why-engineers-should-write/
215 comments
The author of the article is right when he says that writing code is often the easy part of the job for many people. The people who hand out promotions don't read your code, but they do read your writing and hear you speak.
I write documentation, do presentations and demos, do code reviews, and even primarily communicate with colleagues through text. The truth is that people who are better writers have an easier time doing this sort of thing. If the author had emphasized the practical benefits to the average non-influencer-wannabe dev, this article would have been a lot more useful.
I think public speaking classes (or at least practice) and even speech/accent coaching would be beneficial for many developers for the same reasons. Your ideas are only as good as your ability to get people to listen to you, and if you go up the ranks as a developer or transition to management, this only becomes more important.
I write documentation, do presentations and demos, do code reviews, and even primarily communicate with colleagues through text. The truth is that people who are better writers have an easier time doing this sort of thing. If the author had emphasized the practical benefits to the average non-influencer-wannabe dev, this article would have been a lot more useful.
I think public speaking classes (or at least practice) and even speech/accent coaching would be beneficial for many developers for the same reasons. Your ideas are only as good as your ability to get people to listen to you, and if you go up the ranks as a developer or transition to management, this only becomes more important.
If the author had emphasized the practical benefits to the average non-influencer-wannabe dev, this article would have been a lot more useful.
Hey, author here.
I get your point. The internet is filled with pseudo-gurus that try to sell you stuff by writing shit-posts.
I’ve been writing for over 10 years. Many posts were scrapped and thrown away. I’m an autodidact, so I learned from blogs like mine. I try to write quality content only, it’s not always possible, but I try.
The coaching session you mentioned, is indeed free. The newsletter, is free. And you are not obligated to sign to any of them, you can just enjoy the content if it helps you. I tried to design the blog to be as clean as possible, and that posts will be its center.
I also believe that people should be compensated for their efforts. It feels like software engineering is the only industry where people don’t want pay. If I write - I should do it for free, without cringy banners. If I make a software - I should give it away for free with source code attached. If I mentor - I should do it for free. But that’s not how the world works. It’s perfectly ok to give away content for free, which will help to promote other services. And if this makes you anxious, then you should avoid that type of content.
I get your point. The internet is filled with pseudo-gurus that try to sell you stuff by writing shit-posts.
I’ve been writing for over 10 years. Many posts were scrapped and thrown away. I’m an autodidact, so I learned from blogs like mine. I try to write quality content only, it’s not always possible, but I try.
The coaching session you mentioned, is indeed free. The newsletter, is free. And you are not obligated to sign to any of them, you can just enjoy the content if it helps you. I tried to design the blog to be as clean as possible, and that posts will be its center.
I also believe that people should be compensated for their efforts. It feels like software engineering is the only industry where people don’t want pay. If I write - I should do it for free, without cringy banners. If I make a software - I should give it away for free with source code attached. If I mentor - I should do it for free. But that’s not how the world works. It’s perfectly ok to give away content for free, which will help to promote other services. And if this makes you anxious, then you should avoid that type of content.
"Everyone should focus on being an influencer"
Good points, but it does not invalidate the content. I particularly like the structure of this blog post: each title is direct and the paragraph below gives its substance. Structure is paramount for technical writing.
Hahaha I love this community. Every time I read a title like this I am looking for a comment like this ;)
Trite and rehashed groupthink—marketing garbage at its finest. But you should still write. As should every other human being, vocational identity notwithstanding.
Something that I’ve noticed at my company and other companies friends work at is an increasing number of software engineers who do not write code at all. They just write documents, comment on documents, go to meetings, and ask questions in emails. Lots of these types where I work and where my friends work (very well known companies). I do not think this is healthy for a company to have its mid and senior devs writing no code in the numbers I’m seeing.
That sounds like good old Waterfall to me. Or in its current form SAFE. 90% communication 10% code. And something like that is basically what it takes when you have hundreds or thousands of people working on the same product.
Making sure that everyone understands how to use your part (and that the overall architecture is at least coherent), in a big project, is actually more important than if that part is of high quality. And since communication is more important it's the seniors responsibility.
Sometimes I really want to go back to the junior years it was in general more fun back then. But getting to decide the architecture does have its charms.
Making sure that everyone understands how to use your part (and that the overall architecture is at least coherent), in a big project, is actually more important than if that part is of high quality. And since communication is more important it's the seniors responsibility.
Sometimes I really want to go back to the junior years it was in general more fun back then. But getting to decide the architecture does have its charms.
yup, 100% true. If you have not worked in such a big company (say more than 500 people), you can't imagine how much politics/communication/organisation/standards/procedures are important both in term of, well, importance, and time you spend on it. In the company I worked, you had about 1 analyst for 2 devs and 1 PM for 10 persons. So more than one third of the team was never writing code. Add in the time spent in meetings, talks, testing, understanding and yeah, I'm sure about 50% of the time was spent not coding.
It's a consequence of scale. Beyond a critical mass of complexity, it becomes more work to envision the moving parts and orchestrate changes among them, than writing the code itself.
Personally, I think most software systems could accept fewer moving parts if we allowed certain tradeoffs, and the benefit would be much more empowered engineers.
Personally, I think most software systems could accept fewer moving parts if we allowed certain tradeoffs, and the benefit would be much more empowered engineers.
Seems like you put too much value on writing code.
As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable.
Code is liability.
To propose solutions I still need to know the code for the system so it is not like suddenly I lost ability to write or understand code. But coding - is only one of many tools for creating a system.
As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable.
Code is liability.
To propose solutions I still need to know the code for the system so it is not like suddenly I lost ability to write or understand code. But coding - is only one of many tools for creating a system.
> As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable.
Except, this could be done better and cheaper by a literal rock with letters spelling "NO" written on it with a sharpie.
If a software company doesn't write any code, what exactly is it doing? And speaking of bad decisions, surely some have been made already, since everyone is doing the job they're the least qualified for.
Except, this could be done better and cheaper by a literal rock with letters spelling "NO" written on it with a sharpie.
If a software company doesn't write any code, what exactly is it doing? And speaking of bad decisions, surely some have been made already, since everyone is doing the job they're the least qualified for.
> If a software company doesn't write any code, what exactly is it doing
Not all companies are “software companies” and it still takes level of maturity to know when to write code and when to outsource.
At the interview for my n-2 job, I was interviewing with the director of IT and a junior to mid level dev.
The mid level dev asked me how I would write an address validation module.
My answer was that I wouldn’t and went into details all of the complications of validating addresses and that I would use 3rd party CASS software. I went on to explain that from what I know about the core business it wouldn’t be a competitive advantage and that “it wouldn’t make the beer taste better”.
The software dev wasn’t impressed, the director was.
I was hired as a senior dev and I was ruthless about using third party software from reputable companies instead of writing code internally. This company has no desire to hire a bunch of devs.
We had specialized consultants for Salesforce, Workday, our data capture system, learning management systems, AWS and everything else.
In about a year and a half, I put myself out of a job, they went public and are running smoothly seven years later from what I can tell talking to former coworkers.
But I sure did have a great story to tell interviewing for my current position working in the consulting department at BigTech.
Not all companies are “software companies” and it still takes level of maturity to know when to write code and when to outsource.
At the interview for my n-2 job, I was interviewing with the director of IT and a junior to mid level dev.
The mid level dev asked me how I would write an address validation module.
My answer was that I wouldn’t and went into details all of the complications of validating addresses and that I would use 3rd party CASS software. I went on to explain that from what I know about the core business it wouldn’t be a competitive advantage and that “it wouldn’t make the beer taste better”.
The software dev wasn’t impressed, the director was.
I was hired as a senior dev and I was ruthless about using third party software from reputable companies instead of writing code internally. This company has no desire to hire a bunch of devs.
We had specialized consultants for Salesforce, Workday, our data capture system, learning management systems, AWS and everything else.
In about a year and a half, I put myself out of a job, they went public and are running smoothly seven years later from what I can tell talking to former coworkers.
But I sure did have a great story to tell interviewing for my current position working in the consulting department at BigTech.
I see your point.
There's not much more I can add, but there's something I must pick on, in the name of countless users who suffer because of this:
> My answer was that I wouldn’t and went into details all of the complications of validating addresses
So far, so good...
> and that I would use 3rd party CASS software.
Why? The correct answer almost universally is: "I would not do that thing, period, because it's a lose-lose idea that hurts both you and your customers". Same with validating people's names.
EDIT: Since downthread you mention it was a system "for a health care company that sent at home nurses to special needs kids", part of which involved said nurses doing data entry... I wonder how much those nurses loved the address validation "feature" and how many serious issues (as in, with actual consequences to someone's health) it caused.
There's not much more I can add, but there's something I must pick on, in the name of countless users who suffer because of this:
> My answer was that I wouldn’t and went into details all of the complications of validating addresses
So far, so good...
> and that I would use 3rd party CASS software.
Why? The correct answer almost universally is: "I would not do that thing, period, because it's a lose-lose idea that hurts both you and your customers". Same with validating people's names.
EDIT: Since downthread you mention it was a system "for a health care company that sent at home nurses to special needs kids", part of which involved said nurses doing data entry... I wonder how much those nurses loved the address validation "feature" and how many serious issues (as in, with actual consequences to someone's health) it caused.
> Why? The correct answer almost universally is: "I would not do that thing, period, because it's a lose-lose idea that hurts both you and your customers". Same with validating people's names.
For a lot of industries, bulk address verification is a requirement to get a cheaper mailing rate. I first started using it when I was working for a SaaS company that printed and mailed bills and statements to customers.
It also a requirement for medical billing.
For a lot of industries, bulk address verification is a requirement to get a cheaper mailing rate. I first started using it when I was working for a SaaS company that printed and mailed bills and statements to customers.
It also a requirement for medical billing.
Without evaluating the cost of buying and lock in, always going for external software is as wrong as always re-doing it in house.
You’re always locked into your infrastructure.
It made no sense for a health care company that sent at home nurses to special needs kids to write their own in house EMS/EHS system. And they had an in house one that they had been depending on in 2015. It was built using PowerBuilder from 1999 and running SQL Server 2000. They were “locked into” supporting an old PowerBuilder app.
It also wouldn’t have made sense to hire a bunch of mobile developers to write a data capture system written for Android devices for their nurses. I had been there done that eight years prior when I did work for a company that wrote field service software for ruggedized Windows CE devices and 5 years prior when I did something similar for rail car repairmen.
It also wouldn’t make sense for them to write anything that could be done with Salesforce or a third party LMS.
Software developers are a cost center to a non software company.
It made no sense for a health care company that sent at home nurses to special needs kids to write their own in house EMS/EHS system. And they had an in house one that they had been depending on in 2015. It was built using PowerBuilder from 1999 and running SQL Server 2000. They were “locked into” supporting an old PowerBuilder app.
It also wouldn’t have made sense to hire a bunch of mobile developers to write a data capture system written for Android devices for their nurses. I had been there done that eight years prior when I did work for a company that wrote field service software for ruggedized Windows CE devices and 5 years prior when I did something similar for rail car repairmen.
It also wouldn’t make sense for them to write anything that could be done with Salesforce or a third party LMS.
Software developers are a cost center to a non software company.
Having the source internally means: "this software provider can't squeeze us completely dry" though.
We are not discussing "not writing any code" but "writing only code that earns money".
Your company is one consultant away from deciding that your role, as you dont write much code, could be better done by someone who is a full time manager who has an MBA fresh out of university and no coding skills.
By the same token, somebody actively writing code could be said to be one consultant away from being replaced be an offshoring firm.
In the end, knowledge of the business details (including their technical implementation) are something that cannot be easily replaced.
In the end, knowledge of the business details (including their technical implementation) are something that cannot be easily replaced.
I've actually seen these kinds of very-valuable positions replace by the mythical "TPM", who (unless they are very good) has zero hands-on knowledge and wants none. They are worse than unhelpful. A good prin engineer gives all the same schedule updates and cross-functional requirements-wrangling that a mediocre TPM would, but also produces useful code examples, coaching, and PR reviews.
It's the culture of over-communication. In the last 8 year or so, I have noticed my ability to actually write code had dropped through the floor. Everything has to be discussed to death, reviewed, approved, and go through a release process and red tape that would make the US State Department blush. And the end result is still slow and inefficient. There is just no time to make it better as you move on to discuss something else to death, while drowning in a sea of Slack messages.
At one level I understand it. Gone are the days of us hacking away as an island, playing around, experimenting. Software engineering is more mature, boring, and corporate.
At one level I understand it. Gone are the days of us hacking away as an island, playing around, experimenting. Software engineering is more mature, boring, and corporate.
As my career progresses I find myself reviewing code, mentoring, deciding on architecture and running around helping way more people. I still do hands on coding but my workday had completely changed since when I first started out.
As long as they're also reviewing code, I think this is fine. They're scaling their knowledge and impact. Obviously there has to be a healthy ratio of senior:non-senior for this to work as well (maybe 1:4-5?).
I literally had a "senior cloud architect" tell me that he didn't understand how one of his team's apps works because "he only draws the boxes" and then laughed it off.
This is why self-deprecating humour can be dangerous. Some people won't get it and will just think you're an idiot.
Don't worry, he knows what you're thinking. It's probably a paralysing deep sadness for him.
I think there can some some truth to that. As I progressed into more architectural work, you have to leave the deep technical details behind, and you do miss it. But you can't do everything.
This would be normal for any other engineering discipline.
Wow, I've never seen anything like this at the places I've worked. In my experiemce, we could use a role like that.
Eh, careful what you wish for. There's two extremes, and I've had the displeasure of seeing them both.
The first is those who write only code, with no regards for the overall design or documentation of the system, and are completely unable to formulate answers about the high-level functioning of the system, often ask for things based on a low-level need with no regard for what could or should happen at a high level, because nobody has the high level picture.
The other one is armchair architects who will draw system diagrams utterly disconnected from reality, with sub-systems doing things they cannot do, that we will never hire the engineering to do, etc. They'll mandate "common APIs" and "everything must be REST" (but where REST is their personal vision, which is inevitable not RESTful at all, and often is just a bespoke RPC/HTTP style API).
There's a happy medium in the middle: engineers who understand the code, can be productive in the code, but also understand and are making conscious decisions about what the highlevel should be, making design docs, emailing about intentions, etc.
Management has to offer the environment for that to flourish though: there has to be the time for documentation, the time for the design to emerge and for bugs to be worked out. But if everything is just a PM's pet ticket that is due "yesterday" and it must be done because management decrees it and once it is, repeat? Then that'll never happen, and those eng will quickly find greener pastures.
Sometimes it's really petty stuff, too. I've lost the fight of "engineering needs a mailing list to discuss technical changes, TDDs they'd like a review on, etc. There needs to be an alias for engineers to do engineering" — and yeah, no TDDs have happened since!
The first is those who write only code, with no regards for the overall design or documentation of the system, and are completely unable to formulate answers about the high-level functioning of the system, often ask for things based on a low-level need with no regard for what could or should happen at a high level, because nobody has the high level picture.
The other one is armchair architects who will draw system diagrams utterly disconnected from reality, with sub-systems doing things they cannot do, that we will never hire the engineering to do, etc. They'll mandate "common APIs" and "everything must be REST" (but where REST is their personal vision, which is inevitable not RESTful at all, and often is just a bespoke RPC/HTTP style API).
There's a happy medium in the middle: engineers who understand the code, can be productive in the code, but also understand and are making conscious decisions about what the highlevel should be, making design docs, emailing about intentions, etc.
Management has to offer the environment for that to flourish though: there has to be the time for documentation, the time for the design to emerge and for bugs to be worked out. But if everything is just a PM's pet ticket that is due "yesterday" and it must be done because management decrees it and once it is, repeat? Then that'll never happen, and those eng will quickly find greener pastures.
Sometimes it's really petty stuff, too. I've lost the fight of "engineering needs a mailing list to discuss technical changes, TDDs they'd like a review on, etc. There needs to be an alias for engineers to do engineering" — and yeah, no TDDs have happened since!
Yeah so just wanted to chime in here. I 100% agree. I have worked at both extremes.
My current gig is basically the first one. Nobody has the big picture. Nobody wants to discuss the big picture. They are only interested in checking off the boxes associated with the task they currently have assigned. Everything is due yesterday because there is no actual priority list and our priorities shift on a daily basis. It's utter chaos.
We are writing an ERP system. It is slowly shaping up to be a complete disaster. I have spent the last eight months trying to change this approach and attempting to lead by example.
It's not working. I will be moving on soon.
TLDR: Just because somebody can afford to hire a software engineer, doesn't mean they should hire a software engineer.
My current gig is basically the first one. Nobody has the big picture. Nobody wants to discuss the big picture. They are only interested in checking off the boxes associated with the task they currently have assigned. Everything is due yesterday because there is no actual priority list and our priorities shift on a daily basis. It's utter chaos.
We are writing an ERP system. It is slowly shaping up to be a complete disaster. I have spent the last eight months trying to change this approach and attempting to lead by example.
It's not working. I will be moving on soon.
TLDR: Just because somebody can afford to hire a software engineer, doesn't mean they should hire a software engineer.
Sounds like a Business Analyst and perhaps Technical Writer. Not something the developer should usually spend most of their time doing, but a bit is good.
If you aren't writing the code you don't understand the problem and can't possibly write the documentation
Someone reading the code should also be capable of understanding the problem that it solves and documenting the use of the code. If your code is fairly well written, I mean.
Code, like say English poetry, can be subtle. Reading the code can easily answer the question "what does this do?", but it usually doesn't answer "why are we doing it?"
Most importantly it doesn't tell us what we're not doing here, and why not.
I find myself adding comments to my own code when 6 months after the fact I'm re-discovering why something that looks casual is really important. Why that one "obvious " improvement or optimization is -not- done.
But that's documentation at the lowest level. Most of my documentation time (and I'll admit to writing a lot of docs) is about a bigger picture; hoe is the code used, what problems does it solve, how it interacts with the world and so on.
Documentation is not about writing the obvious "this increments x", its about making the code reusable, making it useful to yourself and your colleagues, my noting that it exists.
It I'd if you like the "search index" into the code.
Most importantly it doesn't tell us what we're not doing here, and why not.
I find myself adding comments to my own code when 6 months after the fact I'm re-discovering why something that looks casual is really important. Why that one "obvious " improvement or optimization is -not- done.
But that's documentation at the lowest level. Most of my documentation time (and I'll admit to writing a lot of docs) is about a bigger picture; hoe is the code used, what problems does it solve, how it interacts with the world and so on.
Documentation is not about writing the obvious "this increments x", its about making the code reusable, making it useful to yourself and your colleagues, my noting that it exists.
It I'd if you like the "search index" into the code.
I think you misread the GP. These "mid and senior devs" are writing documents not documentation. They're not writing comments or wiki pages, they're writing designs docs for new systems, proposals for cross-cutting initiatives, etc. They're taking their knowledge of the domain, its issues, and general wisdom and applying it at a scale larger than a single developer's output.
In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done.
For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.
In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done.
For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.
Thank you for not having the obvious and boring take. (I also agree.)
I have seen this more and more as well. In my experience, it tends to be developers who are aiming to switch to project management at some point in their careers.
i'm starting to see this as well.
it's frustrating because capacity planning expects that all engineers / ICs write code at least 75% of their time. the effect is that titles+headcount no longer accurately reflects what are and arent reasonable deliverables / deadlines for a team.
it's frustrating because capacity planning expects that all engineers / ICs write code at least 75% of their time. the effect is that titles+headcount no longer accurately reflects what are and arent reasonable deliverables / deadlines for a team.
> no longer accurately reflects what are and arent reasonable deliverables
Have you ever seen an accurate prediction of this by any methodology?
Have you ever seen an accurate prediction of this by any methodology?
I dunno, it depends entirely on the industry etc; code is, after all, but the final product, the implementation detail of your company. So many (too many?) developers focus too much on code, on output in lines of code, instead of building the right thing.
This is why in a lot of companies, internal tools (like issue trackers, performance monitoring, logging, orchestration, testing, etc) are written and rewritten over and over again. The idea that building your own is better than using off the shelf software. But it's self-gratification, it's avoiding the company's own / real problems and products.
Writing code without a plan or purpose is wasteful.
This is why in a lot of companies, internal tools (like issue trackers, performance monitoring, logging, orchestration, testing, etc) are written and rewritten over and over again. The idea that building your own is better than using off the shelf software. But it's self-gratification, it's avoiding the company's own / real problems and products.
Writing code without a plan or purpose is wasteful.
To be fair, unless you're building some low level infrastructural systems, coding is the easiest part, and code is cheap.
Drop any senior dev into coding duty, and their skills return after one to two weeks. On the other hand, asking a junior dev to implement a new system that integrates with 3 other departments, and you'll have to wait two quarters for them just to figure out who to talk to and how to get consensus.
Drop any senior dev into coding duty, and their skills return after one to two weeks. On the other hand, asking a junior dev to implement a new system that integrates with 3 other departments, and you'll have to wait two quarters for them just to figure out who to talk to and how to get consensus.
This depends on the organisation.
If an enterprise has well defined interfaces for teams to interact with one another and effective escalation points for conflicts in priorities then communication might be the cheap & easy part.
Conversely, small modifications to a messy codebase can be extremely time consuming. Imagine being asked to fix an animation bug on an in house date picker in a large Angular app that hadn't been updated in 5 years.
If an enterprise has well defined interfaces for teams to interact with one another and effective escalation points for conflicts in priorities then communication might be the cheap & easy part.
Conversely, small modifications to a messy codebase can be extremely time consuming. Imagine being asked to fix an animation bug on an in house date picker in a large Angular app that hadn't been updated in 5 years.
[deleted]
bombolo(4)
Donckele(4)
Within the next 24 months that's what all engineers will transition to. Is it healthy or not, it's how it goes. Engineers move to abstract work like architecture, interfaces, and the implementation is handled by AIs, with humans just tweaking when it's not right.
What are you basing this on?
I've played with code generation from AIs it works sometimes but confidently produces bugs and doesn't scale at all.
I think another giant leap is required to get to the point that humans are just tweaking. I'm saying we won't get there but what in the pipeline in the next 24 months that is going to get us there?
I've played with code generation from AIs it works sometimes but confidently produces bugs and doesn't scale at all.
I think another giant leap is required to get to the point that humans are just tweaking. I'm saying we won't get there but what in the pipeline in the next 24 months that is going to get us there?
We all confidently write bugs and discover them in testing. The same process has been implemented for GPT, for example GPT Engineer, you can also instruct the Code Interpreter model for it in GPT Plus and it works. I see some people are not up to date here.
What I base my guess on: the fact we already have GPT apps that write apps and clearly it works fine, and as we like to say "this is the worst it'll ever be". When people say "it's not very good right now, it produces garbage" I only see people who are not used with the speed of progress right now. Midjourney a year ago produced weird abstract doodles that only looked like images from distance. Now it produces photorealistic art that's taking jobs. One year.
What we need: Bigger context, expert models in constellation and scale. You need nothing else. Of course some architectural modifications will emerge in the journey of achieving this, but that's a comparatively trivial constraint to solve, it's just normal software engineering as we've done for decades, but this time for models.
What I base my guess on: the fact we already have GPT apps that write apps and clearly it works fine, and as we like to say "this is the worst it'll ever be". When people say "it's not very good right now, it produces garbage" I only see people who are not used with the speed of progress right now. Midjourney a year ago produced weird abstract doodles that only looked like images from distance. Now it produces photorealistic art that's taking jobs. One year.
What we need: Bigger context, expert models in constellation and scale. You need nothing else. Of course some architectural modifications will emerge in the journey of achieving this, but that's a comparatively trivial constraint to solve, it's just normal software engineering as we've done for decades, but this time for models.
Just because you happen to do a trivial and menial job, it doesn't mean that every software developer does.
[deleted]
First: the AI isn't that accurate yet. It gets shit wrong. It's almost there but not yet. Maybe in 24 months... but a lot of people think we hit a wall.
Second: implementation is harder then design. If AI can do implementation it can for sure do design. And it is demonstrably true that chatGPT can do design just as well if not better than implementation.
Second: implementation is harder then design. If AI can do implementation it can for sure do design. And it is demonstrably true that chatGPT can do design just as well if not better than implementation.
My observations are literally the opposite of what you said so YMMV. Design is where the needs of humans interface with the needs of a machine. Models are good at translating basic needs to code. Not so great knowing or figuring those needs in wider context. Yet. They’re interns.
I'll take that bet.
I will take the other side of this bet.
I don’t see this happening within the next 24 months.
I don’t see this happening within the next 24 months.
We already have apps written by non coders in GPT. But sure let’s wait 24 months.
We also had apps written by "non coders" in excel. We had apps written by some hackthon participants who hadn't coded at all a week before the hackathon. Writing the code is not the hard part of software development, and never has been.
The various LLMs do very poorly at generating and implementing high level designs, especially if they need to generate the specs themselves from a bunch a requirements and/or poorly formulated user feedback.
The various LLMs do very poorly at generating and implementing high level designs, especially if they need to generate the specs themselves from a bunch a requirements and/or poorly formulated user feedback.
You’re reiterating his argument almost perfectly. He initially said the code writing will be left to the AIs while high level designs will be left to the engineers. That’s exactly what they mention foreseeing in the next 24 months, which I also intuitively agree with.
Woooooooooow, a greenfield project developed by a single or a couple of people!
That for sure will scale on larger projects!
That for sure will scale on larger projects!
Don't drink too much of the AI kool-aid.
Do the AI's need those things? I mean, they exist so that humans can understand their 10 million line code bases. Maybe something else will be needed, for AI's to understand their 10 billion line code bases. Something that we won't even be able to discern.
I would add that good writing is required for all career advancement.
Senior engineers or architects may do more design than coding and the design needs to be conveyed likely as writing and hopefully a couple diagrams.
Managers absolutely need to be good writers to communicate effectively, advocate for their team, and tell the story of the team’s work.
If you’re an engineer and want to have a higher level job than you have now, getting better at writing is only going to help. I’m not saying it’s a MUST because I’m sure there’s some outliers, but it won’t hurt.
Senior engineers or architects may do more design than coding and the design needs to be conveyed likely as writing and hopefully a couple diagrams.
Managers absolutely need to be good writers to communicate effectively, advocate for their team, and tell the story of the team’s work.
If you’re an engineer and want to have a higher level job than you have now, getting better at writing is only going to help. I’m not saying it’s a MUST because I’m sure there’s some outliers, but it won’t hurt.
If you want to get ahead, writing will not get you very far. I'm not saying that the skill isn't important, but it's down toward the middle of the list in terms of importance. Most managers are average to terrible writers. And yet at the same time, they invariably tend to be better than average verbal communicators, because being able to connect on a social level is vastly more important than being able to connect through prose. You don't have to trust me on this, just look at how political elections are won. Candidates don't submit long articles to the press that support their positions, they get up on a stage and attempt to connect with crowds on an emotional level. It's no different in business. Senior management wants to have managers who can verbally motivate their employees with a short chat and a pat on the back instead of some essay.
That may be true if you see getting ahead as meaning becoming an ever more senior manager. I do agree that social and verbal skills (and political) skills are important there.
My own verbal and political skills aren't great. I am not a manager! Writing well has been good for me personally in terms of being able to organise my own thoughts better, and to be succinct in a way I can't when I speak.
I find my opinion is consulted frequently partly because I can summarise complex issues and present it in a way others can work with.
My own verbal and political skills aren't great. I am not a manager! Writing well has been good for me personally in terms of being able to organise my own thoughts better, and to be succinct in a way I can't when I speak.
I find my opinion is consulted frequently partly because I can summarise complex issues and present it in a way others can work with.
I'd be pretty surprised if good verbal communicators aren't usually good writers. I think politicians persuade people not by the clarity, conciseness, or coherence of their speech, but by the substance of their speech. If communication itself could be abstracted from the substance of what is communicated, then it wouldn't be true I think to attribute the success of certain politicians to their ability to communicate so much as their ability to choose what to communicate.
A writer has to be interesting though, every piece of writing we consider well written has a quality of gripping the mind. I'd argue then, that politicians though they may not be in the habit of writing long academic style treatises or "interesting" articles, perhaps it can be argued in the past they largely did, still if they are in part elected on the basis of their speech, must possess the same ability in writing.
If you don't believe me then how is it that Trump's tweets are works of art, "I have never seen a think person drinking Diet Coke,"The Coca Cola company is not happy with me--that's okay, I'll still keep drinking that garbage.", etc... Crude, in bad taste, whatever you say. Another example is Obama, who honestly has a gift for writing in the conventional sense.
A writer has to be interesting though, every piece of writing we consider well written has a quality of gripping the mind. I'd argue then, that politicians though they may not be in the habit of writing long academic style treatises or "interesting" articles, perhaps it can be argued in the past they largely did, still if they are in part elected on the basis of their speech, must possess the same ability in writing.
If you don't believe me then how is it that Trump's tweets are works of art, "I have never seen a think person drinking Diet Coke,"The Coca Cola company is not happy with me--that's okay, I'll still keep drinking that garbage.", etc... Crude, in bad taste, whatever you say. Another example is Obama, who honestly has a gift for writing in the conventional sense.
I think it depends who you ask. If you watch most populist speeches, it’s all in the performance. How they move their hands, their bodies, they create an almost theatrical narrative by how they get loud and quiet throughout the speech.
You can also have incredibly skilled orators where it’s all in the substance, but you can really only do that if you message actually has substance to it in the first place.
You can also have incredibly skilled orators where it’s all in the substance, but you can really only do that if you message actually has substance to it in the first place.
This is an interesting position to take. I’ve been back and forth with my N+1 about the utility of sync vs async comms to lead, and I can never nail down a result I’m happy with. Like, sync comms is effective for ladder climbing as you say. But it has failure modes in remote-first teams of ICs across time zones that async comms don’t have. Async comms inherently scale further, too. Maybe their reach is is greater but the impact is lower? I wonder how far recorded video gets. Then you have mentoring juniors - much easier to do synchronously. What’s the appropriate mix?
I agree with you. I consider writing as one of the MOST important skills in life.
However, being an engineer, and writing in my engineering blog, I targeted mainly engineers.
But yeah, everyone will benefit from good writing skills.
However, being an engineer, and writing in my engineering blog, I targeted mainly engineers.
But yeah, everyone will benefit from good writing skills.
It's a shame that more here don't realize that. Being able to communicate is paramount.
In my experience, writing skill rarely matters as much as people think. A large portion of my coworkers won't bother to read what anyone wrote or put effort into comprehending it. I try to make good documentation but I know it's pretty much just for my future self.
This is _exactly_ why it is important.
Most of what you write will be skimmed or not read at all. The only way to increase your odds is to make your writing engaging (to improve chances of it being read) and clear and concise (to improve chances of comprehension).
Another oft overlooked skill is to know when to repeat your message in multiple places, and how to do so without it being irritating or noisy or irrelevant (see also: when not to write anything at all). Again, this increases the chance your message gets across.
Most of what you write will be skimmed or not read at all. The only way to increase your odds is to make your writing engaging (to improve chances of it being read) and clear and concise (to improve chances of comprehension).
Another oft overlooked skill is to know when to repeat your message in multiple places, and how to do so without it being irritating or noisy or irrelevant (see also: when not to write anything at all). Again, this increases the chance your message gets across.
There is no amount of writing skill that allows people to read complex technical documentation without any effort put into reading comprehension. All you're going to do is put your own career on hold as people see you putting large amounts of effort into nothing productive. Dave gets his documentation done in a sprint, why can't you?
Obviously your context will vary. My experience is not your experience.
Early in my career I took something that was technically complex for me, and wrote it up as a book, using the path that lead me to understanding it.
Assuming that some of my peers might benefit from what I learned, I "self published" (aka printed copies on demand on my newly bought double-sided printer) and sold it for $50. I sold about 1000 copies over the next few years.
The money wasn't earth-shattering, but the effect on my career was immense. I was the one who literally "wrote the book". As far as resumes go, it's pretty up there.
Part of the success (I think) was that it was specifically designed to be an easy read. The goal was to get to the end and "know" a bunch of stuff, without it ever being anything but obvious.
I think it was helped by understanding where my own mental blocks were, and by unpicking those blocks, allowed others to easily disassemble and pass them.
In my experience the biggest block to learning is in understanding that something we absolutely positively know to be true, is actually false. Without letting it go first your brain refuses to accept the new (however simple) because it clashes with what is "true". But that's a digression for another thread.
Early in my career I took something that was technically complex for me, and wrote it up as a book, using the path that lead me to understanding it.
Assuming that some of my peers might benefit from what I learned, I "self published" (aka printed copies on demand on my newly bought double-sided printer) and sold it for $50. I sold about 1000 copies over the next few years.
The money wasn't earth-shattering, but the effect on my career was immense. I was the one who literally "wrote the book". As far as resumes go, it's pretty up there.
Part of the success (I think) was that it was specifically designed to be an easy read. The goal was to get to the end and "know" a bunch of stuff, without it ever being anything but obvious.
I think it was helped by understanding where my own mental blocks were, and by unpicking those blocks, allowed others to easily disassemble and pass them.
In my experience the biggest block to learning is in understanding that something we absolutely positively know to be true, is actually false. Without letting it go first your brain refuses to accept the new (however simple) because it clashes with what is "true". But that's a digression for another thread.
Writing a 'book' early in your career definitely sounds like it could open doors but that's a clear edge case. I'm talking about internal documentation. I don't think it's reasonable to put the entire onus of communication on the writer and I've never seen a company value engineers who put large amounts of time into perfecting documentation.
It's completely alien to me that people here seem to believe engineers should be spending time making requirements and architecture documents more engaging. You're paid to read the thing, just read it.
It's completely alien to me that people here seem to believe engineers should be spending time making requirements and architecture documents more engaging. You're paid to read the thing, just read it.
I agree with this, immensely.
Your goal is to get your message across when your writing is skimmed.
That takes immense skill as a writer. Immense skill.
Paris Review is a great book to get an overview of mastering this skill.
Your goal is to get your message across when your writing is skimmed.
That takes immense skill as a writer. Immense skill.
Paris Review is a great book to get an overview of mastering this skill.
As someone struggling to write, doing an engineering blog seems to be a fantastic way to start improving.
One of my gripes about k12 is how english was seen as the opposite of Math/Science.
When in reality these are all intertwined. Logic necessarily uses words. Science might make some equations, but the scientific method is going to use words.
Instead english spent soooo much time on fiction. It really hurt my interest since I was often a contrarian when it came to fiction and my teachers hated it. I thought I was bad at English, turns out teachers didn't like me.
The first time I figured out I was good at English was when my wife, a 4.0 student read a college English paper for me and she was shocked she said "YOU ARE GOOD AT EVERYTHING".
I don't think I was actually that good, I struggle so much writing professional/scientific papers, my readers apparently agree because I'm quite limited in my reach. Meanwhile I see others write juicy content.
Maybe I have a problem with clickbait/marketing/copywriting.
When in reality these are all intertwined. Logic necessarily uses words. Science might make some equations, but the scientific method is going to use words.
Instead english spent soooo much time on fiction. It really hurt my interest since I was often a contrarian when it came to fiction and my teachers hated it. I thought I was bad at English, turns out teachers didn't like me.
The first time I figured out I was good at English was when my wife, a 4.0 student read a college English paper for me and she was shocked she said "YOU ARE GOOD AT EVERYTHING".
I don't think I was actually that good, I struggle so much writing professional/scientific papers, my readers apparently agree because I'm quite limited in my reach. Meanwhile I see others write juicy content.
Maybe I have a problem with clickbait/marketing/copywriting.
> Logic necessarily uses words.
I'm surprised no one has challenged that statement. Logic is making deductive statements that are true. One only needs symbols for this. That's why computers can prove mathematical theorems. Words are necessary because we are human and we need to communicate are base assumptions which normally come from the natural world. Saying logic necessarily uses words is like saying logic necessarily uses eyes or ears.
I'm surprised no one has challenged that statement. Logic is making deductive statements that are true. One only needs symbols for this. That's why computers can prove mathematical theorems. Words are necessary because we are human and we need to communicate are base assumptions which normally come from the natural world. Saying logic necessarily uses words is like saying logic necessarily uses eyes or ears.
Actually this is only half true. Formal logic relies on words because some concepts, like finiteness, are impossible to grasp within the formalism itself. A good textbook on this is “Gödel's Theorems and Zermelo's Axioms A Firm Foundation of Mathematics”, which spends the early chapters dedicated to making you aware of this issue.
I'm not sure I follow, under what formalism does "finiteness" become a concept that's impossible to grasp?
As long as there are humans involved, yes, there are words, even for visual symbols.
> When in reality these are all intertwined.
I'm not a great writer. I hated Norwegian at school.
But I've helped both my SO, my sister and others improve their college grades significantly by simply doing a pass on their hand-ins. They'd write an essay or similar, and I'd just check that their arguments were consistent and made in the right order.
If I found their arguments lacking I'd ask them, they'd explain what they meant and I said "great, put that in there". Other times it was just a matter of swapping segments around. Simple stuff like that.
I wasn't versed in the things they studied, they knew their stuff but they just struggled to put it in writing. I'm not a good writer, it's not what I do. But as a programmer, getting arguments consistent and in the right order, well, that's basically my day job.
I'm not a great writer. I hated Norwegian at school.
But I've helped both my SO, my sister and others improve their college grades significantly by simply doing a pass on their hand-ins. They'd write an essay or similar, and I'd just check that their arguments were consistent and made in the right order.
If I found their arguments lacking I'd ask them, they'd explain what they meant and I said "great, put that in there". Other times it was just a matter of swapping segments around. Simple stuff like that.
I wasn't versed in the things they studied, they knew their stuff but they just struggled to put it in writing. I'm not a good writer, it's not what I do. But as a programmer, getting arguments consistent and in the right order, well, that's basically my day job.
> Instead english spent soooo much time on fiction.
Respectfully, I think this is a vital part of any English education—the more you read, the better your writing becomes. Conversely, it's very difficult to become a proficient writer without becoming a proficient reader first, and for school-aged children, fiction is both the most accessible point of entry (although good nonfiction can capture kids' imaginations, too) and a great way to cultivate analytical skills.
Respectfully, I think this is a vital part of any English education—the more you read, the better your writing becomes. Conversely, it's very difficult to become a proficient writer without becoming a proficient reader first, and for school-aged children, fiction is both the most accessible point of entry (although good nonfiction can capture kids' imaginations, too) and a great way to cultivate analytical skills.
Btw Plato disagrees and I'm with him. (But I am aware of the argument that fiction can intrigue)
Fiction sets unreasonable expectations. Why not use history? The bad guys sometimes win, but at least people learn something closer to reality.
How much time was wasted learning about symbolism? How much time did we waste learning how to be entertained?
Today I do none of this. Non-fiction is far more interesting than someone making stuff up. I'd much rather have good reading and writing skills than the ability to decode entertainment as an adult.
Fiction sets unreasonable expectations. Why not use history? The bad guys sometimes win, but at least people learn something closer to reality.
How much time was wasted learning about symbolism? How much time did we waste learning how to be entertained?
Today I do none of this. Non-fiction is far more interesting than someone making stuff up. I'd much rather have good reading and writing skills than the ability to decode entertainment as an adult.
Fiction gives us things to shoot for, and a way to envision tomorrow. Think about all the things that science fiction envisioned that became reality. Would we have strived for those goals without it? It can also help us understand each other on a level that describing real events can't. Good fiction is art. We need art, and we should be able to be able to interact with it on a sophisticated level. I'm surprised if you honestly find all fiction uninteresting.
History, and I say this with a degree in the subject, does not do the same thing. History too is important, but it is not art, it's a social science. It's a complex field, assuming you mean the study of history and not just telling stories from the past, which half of the time is basically fiction. History is a way for us to understand our past and past and contemporary modes of thought, but it does not fulfill the same role as fiction.
History, and I say this with a degree in the subject, does not do the same thing. History too is important, but it is not art, it's a social science. It's a complex field, assuming you mean the study of history and not just telling stories from the past, which half of the time is basically fiction. History is a way for us to understand our past and past and contemporary modes of thought, but it does not fulfill the same role as fiction.
> Fiction sets unreasonable expectations. Why not use history? The bad guys sometimes win, but at least people learn something closer to reality.
Fiction does not require bad guys to loose. That is just contemporary American cultural expectation to make them always win.
>How much time was wasted learning about symbolism?
If you want to communicate with people, symbolism matters. It is part of the communication, just like analogies or figures of speach.
Fiction does not require bad guys to loose. That is just contemporary American cultural expectation to make them always win.
>How much time was wasted learning about symbolism?
If you want to communicate with people, symbolism matters. It is part of the communication, just like analogies or figures of speach.
Perhaps you should consider the emotional aspects of fiction. There’s more to life than facts.
Life doesn't care how you feel. Life only deals in what you do.
Life doesn't care how I feel, but _I_ do; and I want to live life in a way that makes me (and the people I care about) feel good. Empathy, imagination, and innovation are important for that - and fiction helps feed those.
Empathy and imagination can be found in plenty of non-fiction.
I enjoy reading fiction, mostly for escapism although the good ones also enrich me, but there is plenty of non-fiction that can feed those qualities. Non-fiction that focuses on the psychology, motives and feelings of people, and focuses on special, different , or creative individuals, might dk just that.
The autobiography "Lab Girl" comes to mind.
I enjoy reading fiction, mostly for escapism although the good ones also enrich me, but there is plenty of non-fiction that can feed those qualities. Non-fiction that focuses on the psychology, motives and feelings of people, and focuses on special, different , or creative individuals, might dk just that.
The autobiography "Lab Girl" comes to mind.
Fair point well made!
Sure, you do. Most folks care about how they feel. Life doesn't. It won't. It can't.
You accidentally only read the first ~1/5 of the comment.
The first 1/5th was the only relevant portion to my comment so that's all I replied to. I only stated that life doesn't care. I never said anything about non-fiction, fiction, and/or empathy.
I've been noticing this kind of sentiment online a lot. Seems like a recipe for an accomplished, unhappy life. Ambition, this time for "doing", whatever that means, without considering your and other's happiness.
How does this sound appealing?
How does this sound appealing?
Seems like you're misunderstanding what is being said. Life doesn't care if you have ambition or have a large family and everyone is happy. It doesn't care if you're apathetic and unhappy. It doesn't care if you have cancer or if you were cheated on. It does not care. It cannot care. Life is not sapient nor sentient. It merely is.
> I think this is a vital part of any English education
I wouldn't say "vital". There are plenty of examples everywhere since language is like air. Fiction may be great art, but that's not representative of what most people write. I agree there should be a better balance. When I was growing up we didn't even analyze famous speeches until high school which is far too late.
I wouldn't say "vital". There are plenty of examples everywhere since language is like air. Fiction may be great art, but that's not representative of what most people write. I agree there should be a better balance. When I was growing up we didn't even analyze famous speeches until high school which is far too late.
I think fiction has a place in education for sure, but I think nonfiction, especially longer nonfiction reads (not textbooks, something less dry), should have an equal or slightly larger presence than fiction.
My favorite english class was either technical writing or freshman comp 1 because both were focused on nonfiction pieces, which was so rare elsewhere in my education.
My favorite english class was either technical writing or freshman comp 1 because both were focused on nonfiction pieces, which was so rare elsewhere in my education.
Pictures are worth a thousand words. Writing is reasonably easy and it's hard to get much better than you already are. If I had it to do over again, I'd spend a lot of time learning drawing and diagramming tools. They still intimidate me, and I'm always blown away by people who can whip up a diagram showing exactly what they are thinking.
> Writing is reasonably easy
Incorrect. My professors trashed students reports (that groups had spent literally 800+ man hours on) because they were all awfully written. Writing well is incredibly hard, especially on technical topics.
Diagrams for many engineering topics is worthless since diagrams are unable to actually express complex topics very well.
Incorrect. My professors trashed students reports (that groups had spent literally 800+ man hours on) because they were all awfully written. Writing well is incredibly hard, especially on technical topics.
Diagrams for many engineering topics is worthless since diagrams are unable to actually express complex topics very well.
I had a professor who graded extremely harshly based on the actual grammar and structure of your lab reports. “A large majority of engineering is writing and you all need to figure that out ASAP.”
I’ve had a relatively short career, but he seems to be correct so far.
I’ve had a relatively short career, but he seems to be correct so far.
Pictures are worth a thousand words but if you don't know which words you want to communicate your picture is worthless. Something many artists eventually learn, what is it you actually want to say?
Diagramming is interesting because it relies heavily on writing, half of a diagram are words. You can slap on as many triangles, circles, and lines as you want to communicate your idea but if you do not utilize the right words it's a worthless diagram.
An HTTP request-response diagram is a great example of this. You can overcomplicate it with both symbols and text, you can also miss crucial points and give people the wrong idea entirely.
So let it encourage you to pick up drawing/diagramming tools, and improve your writing even further. Take already made diagrams, how would you improve them? If someone asked for clarity on how to expand on that diagram (ie: how would an ISP fit into the HTTP diagram), what would that look like and what symbols and text would you use?
Another fun challenge to improve on writing is how would you explain (topic) to someone who is blind? It's more difficult than you think as we tend to rely so heavily on visual information, but it's a fantastic way to improve your skills by highlighting weak points in cross-type information.
Diagramming is interesting because it relies heavily on writing, half of a diagram are words. You can slap on as many triangles, circles, and lines as you want to communicate your idea but if you do not utilize the right words it's a worthless diagram.
An HTTP request-response diagram is a great example of this. You can overcomplicate it with both symbols and text, you can also miss crucial points and give people the wrong idea entirely.
So let it encourage you to pick up drawing/diagramming tools, and improve your writing even further. Take already made diagrams, how would you improve them? If someone asked for clarity on how to expand on that diagram (ie: how would an ISP fit into the HTTP diagram), what would that look like and what symbols and text would you use?
Another fun challenge to improve on writing is how would you explain (topic) to someone who is blind? It's more difficult than you think as we tend to rely so heavily on visual information, but it's a fantastic way to improve your skills by highlighting weak points in cross-type information.
> Pictures are worth a thousand words but if you don't know which words you want to communicate your picture is worthless. Something many artists eventually learn, what is it you actually want to say?
If I had a dollar for every time someone drew a diagram that expressed their thought, but didn’t explain all the hidden assumptions and omissions that clear writing would flush out, I would be a poor man since they wouldn’t need me to review their work.
If I had a dollar for every time someone drew a diagram that expressed their thought, but didn’t explain all the hidden assumptions and omissions that clear writing would flush out, I would be a poor man since they wouldn’t need me to review their work.
> Writing is reasonably easy and it's hard to get much better than you already are.
I can't fathom how you've arrived at this conclusion. Like everything in life, the only way you can know for certain if something is true or not is by doing it many times over and then seek feedback.
Until one writes and then shows their writing to many many readers, it is impossible to make such claim.
I can't fathom how you've arrived at this conclusion. Like everything in life, the only way you can know for certain if something is true or not is by doing it many times over and then seek feedback.
Until one writes and then shows their writing to many many readers, it is impossible to make such claim.
> Writing is reasonably easy and it's hard to get much better than you already are.
Dang you and I have complete opposite worldviews on this.
Dang you and I have complete opposite worldviews on this.
> writing is reasonably easy and it’s hard to get much better than you already are
This is the complete opposite of my personal experience. (I do agree with your point about the value of diagramming. But I see it more as a subset of the foundation of writing: clearly expressing thoughts in an easily readable medium
This is the complete opposite of my personal experience. (I do agree with your point about the value of diagramming. But I see it more as a subset of the foundation of writing: clearly expressing thoughts in an easily readable medium
> Writing is reasonably easy
clearly not
give the number
of enginers i see
write like this
all the time
message choke full
of typso
---
All I can figure is that their laptop didn't come with the red squiggle underlining feature, much akin to how some cars on the road very clearly didn't come with a turn signal.
clearly not
give the number
of enginers i see
write like this
all the time
message choke full
of typso
---
All I can figure is that their laptop didn't come with the red squiggle underlining feature, much akin to how some cars on the road very clearly didn't come with a turn signal.
I agree with you! The art of making great images and diagrams, is required as well. But I consider it the next step, after improving your writing skills.
Check out Affinity Designer. There’s a MacOS version and an iPad one - if you have an iPad & pen, definitely get it.
It’s a vector graphics tool - and it’s in a good sweet spot. Easy to make simple and useful diagrams - export them as transparent PNGs and start incorporating them into documents, presentations.
It’s a vector graphics tool - and it’s in a good sweet spot. Easy to make simple and useful diagrams - export them as transparent PNGs and start incorporating them into documents, presentations.
All u need is uml sequence diagram
Chomsky notes that language was evolved not for communication, but for thinking.
Murphy (of Murphy's law fame) notes that you're not really thinking if you don't write the thought down: you just think that you're thinking.
Murphy (of Murphy's law fame) notes that you're not really thinking if you don't write the thought down: you just think that you're thinking.
> From the dawn of times, people were writing.
Nit: before writing was invented, humans were able to pass knowledge over many generations via oral means.[0]
[0] https://www.scientificamerican.com/article/ancient-sea-rise-...
Nit: before writing was invented, humans were able to pass knowledge over many generations via oral means.[0]
[0] https://www.scientificamerican.com/article/ancient-sea-rise-...
While I agree with this article in the main, I cannot believe how poorly written it is.
You're not alone, I thought it was ironic
That's because writing is hard... Like really hard.
I've been tasked with writing a page or two about a project I'm currently working on and I'm finding it incredibly difficult. It has really highlight to me that I need to write more, if I want to be able to communicate more clearly.
I've been tasked with writing a page or two about a project I'm currently working on and I'm finding it incredibly difficult. It has really highlight to me that I need to write more, if I want to be able to communicate more clearly.
Author here. Would you be able to provide constructive criticism of what you didn’t like, so I could improve on it next time?
Sure! The biggest issue is the number of comma splices, which make many of your sentences feel jumbled and disjointed. Aside from that are many more innocent mistakes: “at least” shouldn’t be hyphenated, “ancient” in “ancient Egypt” shouldn’t be capitalized, “one last advice” should be something like “one last piece of advice,” etc. And it could use a good proofing for stuff like “prefect” instead of “perfect” or “make to sense” instead of “make no sense.”
But again, I really dig where you went with the article. I think you make a lot of good points and that your advice to learn by writing is great stuff. It could just use some polish.
But again, I really dig where you went with the article. I think you make a lot of good points and that your advice to learn by writing is great stuff. It could just use some polish.
Thank you very much, I appreciate it. I usually run my articles through proofreading, but I’m in a process of switching to a different text editor, and didn’t setup proofreading yet.
It’s just an excuse though, and I’ll try to be more mindful the next time.
It’s just an excuse though, and I’ll try to be more mindful the next time.
There are some minor grammatical, stylistic, and phrasing issues:
> From the dawn of times, people were writing. We have written using symbols, like in Ancient Egypt. And we have written using letters, like in Renaissance times
"From the dawn of time" is somewhat of a cliché in starting an argument, adding the "s" to "time" makes it a malapropism. This isn't a great way to start a post on the importance of writing. I would generally expect this to be phrased "Since the dawn of time". You, like many writers, have a tendency to over-signify the independence of clauses, leading to a bit of turbulence. Your second and third sentences could be phrased:
"We have written using symbols, like in Ancient Egypt, and we have written using letters, like in Renaissance times"
I'm not going to be a stickler about the "sentences shouldn't start with 'And'". This couplet isn't wrong per se, but the lack of specificity in your writing doesn't exactly scream "I know the history of the written lanuage!" Don't be afraid to be specific. In both the cases of Egypt and the Renaissance there were earlier cases of symbol-based and letter-based writing systems. Researching, naming them, and giving the reader that extra bit of context will make your writing more engaging.
There are also tense conflicts between these two sentences: one is firmly rooted in the past tense while the other lands in the present perfect tense. This is a big ol' nitpick but once you start really paying attention to tense you start to notice that tense-disagreement can make writing sound disjoint. One way this could be rephrased or improved upon is to focus on tense agreement and be more direct in what you're saying:
"Since at least 3400 years ago, people have used writing to communicate ideas. Ancient Egyptians and Mesopotamians had complex language systems that revolved entirely around the use of symbols. As language evolved, words and letters gave writers a near-infinite sandbox of concepts and tools with which to communicate. By the time of the Greeks, alphabetic languages like Aramaic, Hebrew, and Sanskrit were used the world over to preserve and communicate ideas."
A few more examples:
This is a big misconception, we all fall for. -> This is a big misconception that many software engineers fall for. (comma overuse) (unclear "we") (overgeneralization in using "all")
One simple way to write more–is to approach design reviews in a different way. Instead of hating them, and doing them like a homework assignment, try to approach them with enthusiasm -> One simple way to write more is to approach design reviews in a different way. Instead of hating them or treating them like a homework assignment, try to approach them with enthusiasm (hyphen misuse, comma overuse)
One last advice–abolish the copy-paste. So many developers, whom I mentored, simply copy-paste everything. Code snippets, function declarations, etc. I know how to initialize a git repository, because I do it by hand every time -> One last piece of advice: abolish the copy-paste. Many developers I have mentored simply copy-paste everything from code snippets to function declarations. I know how to initialize a git repository because I do it by hand every time. (comma overuse, hyphen misuse, unnecessary sentence snippet).
I would like to echo the other commenter that I really agree with the message here, and think it's illustrative that you're getting feedback on your writing after posting it here. If you never write, nobody will ever have the chance to give you feedback. Keep it up!
> From the dawn of times, people were writing. We have written using symbols, like in Ancient Egypt. And we have written using letters, like in Renaissance times
"From the dawn of time" is somewhat of a cliché in starting an argument, adding the "s" to "time" makes it a malapropism. This isn't a great way to start a post on the importance of writing. I would generally expect this to be phrased "Since the dawn of time". You, like many writers, have a tendency to over-signify the independence of clauses, leading to a bit of turbulence. Your second and third sentences could be phrased:
"We have written using symbols, like in Ancient Egypt, and we have written using letters, like in Renaissance times"
I'm not going to be a stickler about the "sentences shouldn't start with 'And'". This couplet isn't wrong per se, but the lack of specificity in your writing doesn't exactly scream "I know the history of the written lanuage!" Don't be afraid to be specific. In both the cases of Egypt and the Renaissance there were earlier cases of symbol-based and letter-based writing systems. Researching, naming them, and giving the reader that extra bit of context will make your writing more engaging.
There are also tense conflicts between these two sentences: one is firmly rooted in the past tense while the other lands in the present perfect tense. This is a big ol' nitpick but once you start really paying attention to tense you start to notice that tense-disagreement can make writing sound disjoint. One way this could be rephrased or improved upon is to focus on tense agreement and be more direct in what you're saying:
"Since at least 3400 years ago, people have used writing to communicate ideas. Ancient Egyptians and Mesopotamians had complex language systems that revolved entirely around the use of symbols. As language evolved, words and letters gave writers a near-infinite sandbox of concepts and tools with which to communicate. By the time of the Greeks, alphabetic languages like Aramaic, Hebrew, and Sanskrit were used the world over to preserve and communicate ideas."
A few more examples:
This is a big misconception, we all fall for. -> This is a big misconception that many software engineers fall for. (comma overuse) (unclear "we") (overgeneralization in using "all")
One simple way to write more–is to approach design reviews in a different way. Instead of hating them, and doing them like a homework assignment, try to approach them with enthusiasm -> One simple way to write more is to approach design reviews in a different way. Instead of hating them or treating them like a homework assignment, try to approach them with enthusiasm (hyphen misuse, comma overuse)
One last advice–abolish the copy-paste. So many developers, whom I mentored, simply copy-paste everything. Code snippets, function declarations, etc. I know how to initialize a git repository, because I do it by hand every time -> One last piece of advice: abolish the copy-paste. Many developers I have mentored simply copy-paste everything from code snippets to function declarations. I know how to initialize a git repository because I do it by hand every time. (comma overuse, hyphen misuse, unnecessary sentence snippet).
I would like to echo the other commenter that I really agree with the message here, and think it's illustrative that you're getting feedback on your writing after posting it here. If you never write, nobody will ever have the chance to give you feedback. Keep it up!
How do I learn to analyse and critique my own writing in this way?
It’s broader than just grammar, more like rules for good writing which could almost be automated.
Are there a set of rules or a good book I can refer to?
It’s broader than just grammar, more like rules for good writing which could almost be automated.
Are there a set of rules or a good book I can refer to?
Steven Pinker's _The Sense of Style_ is good at grounding style rules in the actual evolved structures of human grammar.
I also recommend the left-to-right, "topic position -> stress position" approach described in https://www.americanscientist.org/blog/the-long-view/the-sci.... I care more about whether I am making the reader do unnecessary work than whether I am entertaining to read or whether my commas are spliced.
I also recommend the left-to-right, "topic position -> stress position" approach described in https://www.americanscientist.org/blog/the-long-view/the-sci.... I care more about whether I am making the reader do unnecessary work than whether I am entertaining to read or whether my commas are spliced.
Eats, Shoots & Leaves is a good one on punctuation. Dreyer’s English is a good recent one. Woe Is I is a classic. There are a lot of style guides and fun little books about grammar and editing. My partner is a editor at a publishing house so she guides me a lot on things like this. I’m not sure it can be automated, but the best things I can say I’ve learned about writing are: don’t do anything obviously wrong (grammatically, syntactically, factually), be concise/specific, and keep your purpose/relationship to the reader at the front of your mind.
There is a great book called _Style: Towards Clarity and Grace_. Any of Joseph Williams' other books will do if you can't get hold of that.
Don't want to sound overly negative, but the while article is just rehearsing a bunch of platitude about writing...
Also "all great engineer are great writer of code ?"... no not really coding and good engineering are different skills
Also "all great engineer are great writer of code ?"... no not really coding and good engineering are different skills
Any engineer that went to college should have taken multiple technical writing classes. Engineering school vigorously demands that you learn how to write properly and accurately, something that seems lost on "web engineers"
The problem with school, or college, is that they tell you, you need to write. They don’t explain to you why you need to write, and what are the benefits of writing.
That’s why most design reviews are very painful to read, and understand. That’s why company wiki becomes a pile of useless information.
That’s why most design reviews are very painful to read, and understand. That’s why company wiki becomes a pile of useless information.
> They don’t explain to you why you need to write
That is a failure of the professor. I was blessed to have a professor with an engineering degree, a writing degree, and industry experience as a technical writer. He was uniquely qualified to teach engineers how to write and why good writing was important.
That is a failure of the professor. I was blessed to have a professor with an engineering degree, a writing degree, and industry experience as a technical writer. He was uniquely qualified to teach engineers how to write and why good writing was important.
> They don’t explain to you why you need to write, and what are the benefits of writing.
Then thats a bad school or program. It was drilled into us nonstop that lives depend on writing good reports. You do not want to be the person blamed because your report was vague or misleading. Bad writing kills people.
Then thats a bad school or program. It was drilled into us nonstop that lives depend on writing good reports. You do not want to be the person blamed because your report was vague or misleading. Bad writing kills people.
It really doesn't. I got an engineering degree without taking a single technical writing course. Not counting short physics lab write-ups, I think I wrote a single technical paper during undergrad.
You didn't do a capstone project? My capstone was half engineering, half technical report writing. The engineering section was considered worthless unless you wrote a acceptable report. Nobody cares about what you built unless you can write a proper report about it.
How is that possible?
How is that possible?
Yeah, that project was the one paper, but there was essentially no focus on technical writing in the course. And even if it were half on technical writing, half of a single semester is hardly a major focus for a degree program. It's rather underemphasized.
This is part of the reason why "engineer" is a protected title in many places.
I've never heard of CS undergrad programs requiring a technical writing (TW) course, let alone many. Can we do a quick poll? Leave a comment with the name of the university where you got your CS undergrad degree, the year (or decade) you graduated, and whether or not TW courses were required.
EECS at Cal for example doesn't seem to require any TW classes: https://eecs.berkeley.edu/academics/undergraduate/cs-ba
EECS at Cal for example doesn't seem to require any TW classes: https://eecs.berkeley.edu/academics/undergraduate/cs-ba
Loyola University Maryland, 2012, I don’t know if a technical writing course even existed.
Edit: But I do want to note that I love and appreciate good technical writing, and have gotten a lot of experience doing it in the workplace. It’s a really important skill, but with undergrad curriculum so jam-packed already, I can see why it might not be a required full-semester course.
Edit: But I do want to note that I love and appreciate good technical writing, and have gotten a lot of experience doing it in the workplace. It’s a really important skill, but with undergrad curriculum so jam-packed already, I can see why it might not be a required full-semester course.
University of Michigan, 2012, a technical writing course was required (TCHNCLCM 300) and it's still required: https://docs.google.com/document/d/1Vh83l2mW6j9P91eqV4W3UbqU...
sewing thread emoji
(Yes, but it was combined with an operating system class.)
(Yes, but it was combined with an operating system class.)
Anyone who went to college should have taken multiple classes that require you to write. Myopic "engineering schools" miss the point of higher learning.
I picked Engineering as it didn't have any writing requirements. Now I wish I'd spent more time writing. It's a skill that I need and want to develop now that I understand how the world works better than I did as a university student.
I've never taken a technical writing class but I did work on school newspapers and also took English classes that involved writing.
If you're looking for a distraction-free writing tool, I've been building and using a minimal blogging platform called Tinylogger[1]. My focus is on a totally clean interface (everything goes away while you write [2]), and I recently shipped a no-judgement mode [3] that focuses you only on the line you're writing, fading everything else out - perfect for first drafts and morning pages. I've been blogging a lot more this way.
[1] www.tinylogger.com
[2] https://twitter.com/maxverse/status/1666095452520058884
[3] https://twitter.com/maxverse/status/1665729476574019585
[1] www.tinylogger.com
[2] https://twitter.com/maxverse/status/1666095452520058884
[3] https://twitter.com/maxverse/status/1665729476574019585
I was hoping the article would compare how writing code and writing a fantasy, sci-fi, etc. novel are very similar. I find writing stories to be a better analogy to use with programming than civil engineering or architecture.
Its very easy for another engineer/architect to look at some building plans and make an addition to the structure. Now compare that to how easy it is for a different writer to finish the work of another. The second is a lot more difficult to do. This is probably the reason why rewriting is always the default choice when a new group takes over a code-base.
The big difference is that in programming you have instant feedback when something is inconsistent in the story (compilers/interpreters). Writers have that too, they are called fans but they're not as reliable and not every writer gets that luxury.
Its very easy for another engineer/architect to look at some building plans and make an addition to the structure. Now compare that to how easy it is for a different writer to finish the work of another. The second is a lot more difficult to do. This is probably the reason why rewriting is always the default choice when a new group takes over a code-base.
The big difference is that in programming you have instant feedback when something is inconsistent in the story (compilers/interpreters). Writers have that too, they are called fans but they're not as reliable and not every writer gets that luxury.
I feel a disconnect between what the writer probably wants to say (which is kinda meh...everyone's brain is different, good for the author if he found something he enjoys), and the actual argument they're pushing, which is more interesting to be honest.
> All engineers are good writers… of code.
> Writing is a way to organize your brain
> Writing is a way to learn something
> Writing helps you identify mistakes
> Remember–reading is a habit, writing is a skill. And in order to prefect your skill, you need to write more.
Basically, "write more code if you're good at it, you'll learn a lot, organize your brain, and improve your skills" is also a decent takeway from this.
> All engineers are good writers… of code.
> Writing is a way to organize your brain
> Writing is a way to learn something
> Writing helps you identify mistakes
> Remember–reading is a habit, writing is a skill. And in order to prefect your skill, you need to write more.
Basically, "write more code if you're good at it, you'll learn a lot, organize your brain, and improve your skills" is also a decent takeway from this.
I do find that really interesting actually, though I disagree in the context of Code, reading is not a habit, it's a skill you need to practice.
I've read an iteration of this blog post every week for the last decade, but something I've been doing recently and has actually helped (far more than writing) which I've not ever read a blog post about is simply explaining technical concepts out loud to myself.
I'm a very bad communicator due to being autistic and unlike writing as developer I often find myself in position where I need to discuss some technical concept with other developers on the team. Occasionally I also have to communicate technical aspects of my work with those on the team who are non-technical. I really struggle with this.
At the end of each day I'll now do a 10 audible recap of what I've done. Anything I struggle to explain I spend a little time thinking about how I can be clearer and try again until I'm happy. I then take some notes and I have something for standup the next day, but also I'm hoping that consciously focusing on how I explain things is helping a with my ability to explain things on fly.
I'm a very bad communicator due to being autistic and unlike writing as developer I often find myself in position where I need to discuss some technical concept with other developers on the team. Occasionally I also have to communicate technical aspects of my work with those on the team who are non-technical. I really struggle with this.
At the end of each day I'll now do a 10 audible recap of what I've done. Anything I struggle to explain I spend a little time thinking about how I can be clearer and try again until I'm happy. I then take some notes and I have something for standup the next day, but also I'm hoping that consciously focusing on how I explain things is helping a with my ability to explain things on fly.
I'm still in the early stages of learning how to code, but I've started doing something similar to help me get into the right mental state. As someone with severe ADHD, it takes serious effort to get the brain waves waviating at the right frequencies. If I mentally check out, even for a couple of hours, it's like I completely forget everything I've worked on.
Out of frustration, I started talking through my code out loud, and the difference was incredible. All my mental scaffolding and abstractions sprang to life, where before it would've taken an hour or two of rereading my code and rebuilding everything in my mind. Now I'm a chatty bird, typing and mumbling to myself as I work.
Also, not to discount your struggle, but don't write yourself off as a bad communicator—pun intended. I spent 15 years in tech, then seven years writing marketing content, and now I'm transitioning back to tech. Words are hard. The ability to string them together coherently does not make someone a great communicator. Like writing code and engineering, it's easy for laymen to conflate the skill with the vocation.
Keep practicing—you'll eventually outshine those who think opening their mouths and making noises is necessarily good communication. And check out some famous speakers who're on the spectrum if you haven't—you'd be surprised.
Out of frustration, I started talking through my code out loud, and the difference was incredible. All my mental scaffolding and abstractions sprang to life, where before it would've taken an hour or two of rereading my code and rebuilding everything in my mind. Now I'm a chatty bird, typing and mumbling to myself as I work.
Also, not to discount your struggle, but don't write yourself off as a bad communicator—pun intended. I spent 15 years in tech, then seven years writing marketing content, and now I'm transitioning back to tech. Words are hard. The ability to string them together coherently does not make someone a great communicator. Like writing code and engineering, it's easy for laymen to conflate the skill with the vocation.
Keep practicing—you'll eventually outshine those who think opening their mouths and making noises is necessarily good communication. And check out some famous speakers who're on the spectrum if you haven't—you'd be surprised.
I'd argue that this is a form of rubberducking.
Something that I've tried a few times was basically pretending that I'm a live-streamer/YouTuber/whatever and verbally explain my thought process & actions as I program. I found that it was actually better practice for coding interviews than anything else, but I wouldn't be surprised if you found trying something similar also helpful.
I do think there is specific value in practicing summaries, though, as it's a really important skill to be able to distill down a 45-minute technical rant into something grokkable by others in a reasonable amount of time. Something that I do most mornings is plan out my exact phrasings for standup updates, sometimes verbally if I'm having troubles putting my update into words and I'm WFH that day. Then again, I'm probably a bit autistic too and often mentally plan out most non-casual conversations.
Something that I've tried a few times was basically pretending that I'm a live-streamer/YouTuber/whatever and verbally explain my thought process & actions as I program. I found that it was actually better practice for coding interviews than anything else, but I wouldn't be surprised if you found trying something similar also helpful.
I do think there is specific value in practicing summaries, though, as it's a really important skill to be able to distill down a 45-minute technical rant into something grokkable by others in a reasonable amount of time. Something that I do most mornings is plan out my exact phrasings for standup updates, sometimes verbally if I'm having troubles putting my update into words and I'm WFH that day. Then again, I'm probably a bit autistic too and often mentally plan out most non-casual conversations.
I do this by writing stuff into my notes, but yes! Oftentimes this even improves the solution you were trying to explain. Sure `poetry lock --no-update` fixed it, but why was it updating in the first place...? and I go back to discover an open issue in PyTorch 2.0.1, so I can solve the problem for good by skipping that release.
While I agree, reading is the other part. I - and so many others here I'm sure - have spent so much time answering questions that were documented. It's just that nobody reads the documentation, or can't find what they need fast enough, or they just have no patience because asking someone feels faster - to them.
I can write long documentations and comments on everything, but it's wasteful if it's not kept up to date and it's waste if nobody bothers to read it.
I can write long documentations and comments on everything, but it's wasteful if it's not kept up to date and it's waste if nobody bothers to read it.
Interesting point! I would take it further and say that it’s not about reading, but about being able to find the needed information.
I won’t read the entire git book, if I only want to create a new branch. I should be able to find it.
I won’t read the entire git book, if I only want to create a new branch. I should be able to find it.
With others here I deplore that my schools did not teach a number of important life and career skills including writing. They did teach english, did an excellent job of it. But they did not teach writing FAST. By now I feel a key to productivity (or plain day to day viability) is being able to draft, reorganize, prune, edit and ship out FAST. That deserves teaching.
Hilariously, most Google hits in this direction are about handwriting speed. I have to add "productivity" and the like to get anywhere.
Hilariously, most Google hits in this direction are about handwriting speed. I have to add "productivity" and the like to get anywhere.
Writing is also a very useful tool for guiding/directing the conversation.
Create a document that lays out the approach you want, share it, and then have a meeting about it where people can react to it. If you get everyone together and try to decide something democratically, it's a shit show. Documents allow you to put a stake in the ground, and depending on how much colleagues care, what you write is 95% of what ends up in the product.
Create a document that lays out the approach you want, share it, and then have a meeting about it where people can react to it. If you get everyone together and try to decide something democratically, it's a shit show. Documents allow you to put a stake in the ground, and depending on how much colleagues care, what you write is 95% of what ends up in the product.
"All engineers are good writers… of code". Wow wrong in the first sentence. Glad I didn't waste my time reading this article.
It's not about engineers only. Every human who can read and write MUST form a habit of writing. It does not matter you write in Shakespearean language or not, what matters you convert your thoughts into words. If you feel embarrass of sharing your thoughts, just do it privately, in a diary or online private blogs like Wordpress but DO WRITE ANYWAY!
For me, the biggest obstacles to improving in writing is getting feedback. It's hard because you need to ask people to read what you wrote and feedback is very subjective.
It's really different from software development where you can get immediate feedback without outside help(I am aware code reviews exist).
It's really different from software development where you can get immediate feedback without outside help(I am aware code reviews exist).
Feedback is subjective in every field you take. I’ve got a lot of “NITs” in my code reviews, which essentially are - subjective feedback.
I do see where you are coming from regarding getting feedback. I’m pretty sure there are places, like Reddit communities, where you can get feedback about writing.
But I also want to point out an interpreting observation, that I can’t explain. I’ve noticed that the more I write, the better I become at it, regardless of whether I get feedback or not. Future articles are becoming easier to write, sometimes clearer. I also see an improvement in my oral communication. So maybe practice, for the sake of practice - does make perfect.
I do see where you are coming from regarding getting feedback. I’m pretty sure there are places, like Reddit communities, where you can get feedback about writing.
But I also want to point out an interpreting observation, that I can’t explain. I’ve noticed that the more I write, the better I become at it, regardless of whether I get feedback or not. Future articles are becoming easier to write, sometimes clearer. I also see an improvement in my oral communication. So maybe practice, for the sake of practice - does make perfect.
What if you wrote code as a form of communication - demos, proof of concepts, snippets.
This would work - but only if the people you communicate to are software literate.
Yes english matters but sometimes it's just easier to write code to show the ideas work
This would work - but only if the people you communicate to are software literate.
Yes english matters but sometimes it's just easier to write code to show the ideas work
The thing with writing code, is that often time, engineers are moving away from working with other engineers.
The more scope you get at your work, the more you work with non coding people: an architect that might not code in your language, a PM who might not code at all, a team lead who is not a programmer, a potential client.
The more scope you get at your work, the more you work with non coding people: an architect that might not code in your language, a PM who might not code at all, a team lead who is not a programmer, a potential client.
My implication is that they should read code. Software literacy needs to be society wide.
Look loads of managers these days say "I used to code but now I moved to management I don't do that."
No one says "I used to read and write English but now I have moved to management I don't do that". Because sometime around 1500 using writing to communicate and set policy became so powerful that's how you ran a large (religious) organisation (in Europe).
Look loads of managers these days say "I used to code but now I moved to management I don't do that."
No one says "I used to read and write English but now I have moved to management I don't do that". Because sometime around 1500 using writing to communicate and set policy became so powerful that's how you ran a large (religious) organisation (in Europe).
The don't copy paste statement is eh. Reads like do everything by hand.
When I can google the answer in a min. Or if you use AI, even less, why bother?
Our brains can be used for more important details than how do I reset a git branch.
When I can google the answer in a min. Or if you use AI, even less, why bother?
Our brains can be used for more important details than how do I reset a git branch.
My farourite example is vim. Typical scenario of using it is when you do not know what key to press for doing some simple thing but then you put your hands on the keyboard and they do all the work without even involving the brain.
Is there any empirical evidence for these claims?
It seems to me writing about learning a new programming language makes you better at writing, not necessarily better at learning the new programming language
It seems to me writing about learning a new programming language makes you better at writing, not necessarily better at learning the new programming language
"From the dawn of time, people were writing" In conclusion, there are positives and negatives to writing better as an engineer
The only thing engineers should focus on is, well,engineering.
I rarely learned anything meaningful from "X should do Y" types of posts.
Hey! Author here.
What type of posts help you learn meaningful things? I try to improve my writing all the time, and would love to experiment with other formats, that might benefit more people.
What type of posts help you learn meaningful things? I try to improve my writing all the time, and would love to experiment with other formats, that might benefit more people.
> Each time you write a design review
What is this? I've never had to write one.
What is this? I've never had to write one.
[deleted]
Financial advisers are exactly the same with their "weekly newsletters" that seem to do nothing more than make you anxious about your financial portfolio and think: "Hey, I need some coaching!"