This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
One of the top discussion site-wide over the past week was Opinion: Architect VS Engineer VS Developer. There were two responses that really stuck out, offered by @phlashgbg and @chrismcleod:
I'll bite :)
I have had all those titles, and it makes little to no difference to what I do, and quite a lot of different to how I'm perceived.
First contact with suppliers or customers: it's useful to set an expectation of authority so I'm an Architect - they feel valued and we can get going quicker on working together (or coming to agreed separation).
With team members I will be working with: I introduce myself as the fool responsible for the poor decisions, taking some pressure off them, suggesting that good decisions are made by others and demonstrating the humour necessary for survival in a work environment :) Over time they can decide for themselves on my actual skills!
Would I be offended by being a known as a 'coder'? Nope, quite the opposite: that means someone thinks I can in fact write code, and will understand what I'm looking at (possibly their efforts, possibly my latest PoC mess), a fellow geek, not a weird out-of-touch golf-course decision making 'Architect' in an ivory tower somewhere.
In terms of what I do: architecture is a role on a team, equal valued to other roles, with different focus and outcomes (big picture goals, communication with stakeholders, etc.) it's my T-shaped specialism, other folks enjoy theirs and together we get stuff done. If we're doing it right then mentoring takes place and others get to learn some system and business scale patterns from me while I learn something from them.
Architect selects tools, frameworks, paradigms best suited for the job. Example: the person that draws a blueprint has selected the shape and materials for a house.
Engineer solves a real-world problem using software/algorithmic principles and coordinates with stakeholders. Example: a foreman consumes a blueprint but decides in which order things will be done, best practices for assembling components of the house, guides implementation etc.
Developer implements the solution; they are developing the software by bugfixing, refactoring, etc. Example: general laborers hammer in the nails when it is time to frame a house and tear down walls when it is time to remodel.
All of these are not titles but modes of operation that a single person can be working in at any given time. Each person will have varying degrees of proficiency at each important task and so when it comes time to titleize, may prefer a specific title.
IMO.
Answering What does a dev's personal website need to include?, @ben shares a no-nonsense list — ironic considering his wonderfully nonsense-filled personal site:
- It should load quickly. Render static from a CDN.
- It should get to the point. Describe your skills and interests.
- It should link to things you’ve written.
- It should link to your profiles: GitHub, DEV, etc.
- It shouldn’t be overly fancy, or generic. Make it unique but understated if possible. Going to flashy can really be a bad idea in web design.
- It probably shouldn’t look like this
@gabcimato offer some thoughts in perspective in the How to find open source projects as a new developer? thread:
To be honest when I started a while ago I was on the same boat. I stopped worrying about finding an open source project I could contribute to because it felt forceful. Instead I continued studying and practicing.
Nowadays I make PRs after I have been using a library, node package, framework, for any of the projects I'm working on (either personal or required by my job). Sometimes it's a typo on the docs, sometimes it's adding more examples on docs and eventually it's a new feature or a bugfix. As others mentioned, there are projects with issues beginners-friendly if you wanna really dig into it.
But what I found more "natural" is just working on a project and...getting frustrated! Then I address that frustration with the hope of preventing anyone else to fall into the same trap. The way I address it is usually with a PR!
So go ahead and try to build something. If you use a library and the docs are confusing, submit a PR! You find a typo, submit a PR! You find a bug, try to your best to fix it and if you can't, open an issue!
Finally, I wanted to highlight the Welcome Thread - v31 with @defgrav04's introduction comment:
Hello everyone,
I’m Mina, a Java developer turned C# developer. Although I’m a senior at my work, I still feel like there’s so much to learn. I think that’s the beauty of programming — constant learning.
I also blog on my spare time and am learning React natve. I’ve always dreamed of publishing an app but never really got around to it. I now focus more on writing on my blog (craftedserendipity.com) and programming.
My manager sent me an article from dev.to about code reviews. It piqued my interest so much that I decided to join the community.
Excited to learn from passionate, like-minded people, and to contribute my ideas and experiences to the community. :)
The #welcome tag contains a recurring thread where new community members introduce themselves. It's a fun place to greet new folks, ensuring that everyone feels welcome and included. If you've never done so (and even if you have), consider hopping into the thread to welcome some new DEV community members!
See you next week for more great comments ✌
Top comments (1)
Congrats @phlashgbg , @chrismcleod , @ben , @gabcimato , and @defgrav04 for making the list this week!