Top 5 DEV Comments from the Past Week

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.

• 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

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!

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. :)